Webservice Restituisce il tipo di risultato generico o il tipo di risultato desiderato

Question

Webservice Restituisce il tipo di risultato generico o il tipo di risultato desiderato

#1 da (2 voti)

1

Sto costruendo un servizio web che restituisce JSON / XML / SOAP al momento .. e non sono del tutto sicuro di quale sia l'approccio migliore per restituire i risultati.

Il Cliente che consuma i Servizi sarà generalmente Applicazioni Web / Applicazioni Web mobili. Ma potrebbe provenire da vari sistemi di tipo WordPress e altri social media Plugin.

Quale sarebbe un valore di ritorno migliore?

Una struttura di tipo "trasferimento" generica, che trasporta proprietà generiche o un tipo proposto con proprietà distinte:

class GenericTransferObject{
    public string returnVal;
    public string returnType;
}

VS

class PurposedTransferObject_1{
  public string Property1;
}

//and then building additional "types" for additional values
class PurposedTransferObject_2 {
  public string PropertyA;
  public string PropertyB;
}

Ora, questo sarebbe il serializzato e restituito da una chiamata al servizio web tramite una tecnologia client, JQuery in questo esempio. SO se ho chiamato:

/ GetDaysInWeek /

Vorrei tornare indietro:

{"returnType": "DaysInWeek", "returnVal": "365" }

o

{"DaysInWeek": "365"}

E poi andrebbe da lì.

Da un lato c'è flessibilità con il primo esempio. Posso aggiungere "returnTypes" senza dover aggiustare il client se non facendo riferimento a un ulteriore "indice" ..

ma se dovessi aggiungere una proprietà, ora sto cambiando la definizione di una struttura ..

C'è una scelta ovvia in questa situazione?

c# javascript asp.net-mvc microsoft

posta hanzolo 19.09.2012 - 08:07

fonte

1 risposta

Leggi altre domande sui tag c# javascript asp.net-mvc microsoft

Buon esempio di gprof, per il progetto iOS 2 Server 1 Database - Posso usare Redis?

score 2 · Accepted Answer

Penso che per la maggior parte delle cose staresti meglio con le proprietà distinte e tipizzate negli oggetti per scopi specifici per diversi motivi:

Rende più facile per alcuni clienti consumare le tue entità. Ad esempio ci sono parser JSON e XML che creeranno automaticamente le rappresentazioni dei tuoi oggetti da strumenti esistenti. Da un lato questo comporta un onere maggiore con la rappresentazione non standard più generica (simile al problema con EAV nei database SQL).
Il consumo di clienti potrebbe essere meno fiducioso del contratto implicito dell'API per fornire modifiche senza interruzioni con le rappresentazioni più lente e sarebbe facile creare accidentalmente modifiche di rottura difficili da risolvere.
Sarà più difficile rappresentare altri tipi di valore di dati se tutto è una stringa. Dovresti aggiungere un'altra proprietà chiamata "returnValuetype" e poi inizia a diventare eccessivamente disordinata poiché dovrai controllarla anche nel tuo parser. Ci sono già abbastanza problemi con le rappresentazioni della data-ora.