Interfaccia servizio Web - Tipo complesso come parametro?

Solo in cerca di feedback sulle best practice relative alla progettazione dell'interfaccia Web Service.Interfaccia servizio Web - Tipo complesso come parametro?

ho due opzioni:

Opzione 1

public string GetSomeData(SomeCriteriaClass criteria);

dove SomeCriteriaClass è definito come:

public int ID; 
public string Name; 
public string Property2; etc.

Opzione 2

public string GetSomeData(int id, string name, string property2)

Qual è l'opzione preferita? Sembra un conflitto di schemi di progettazione: 1 è quello di racchiudere i parametri in una classe, mentre l'altro è mantenere l'interfaccia del servizio Web flessibile e aperta.

La seconda domanda è: se scegliamo Opzione1, come si chiama tramite un URL?

Grazie

fonte

2009-05-19 Duncan

Perché dici che l'opzione 2 "mantiene l'interfaccia del servizio Web flessibile e aperta"? Significa che qualsiasi modifica ai parametri dei dati influirebbe sulla dichiarazione dell'API, mentre nell'opzione 1 interesserebbe solo la dichiarazione "classe parametro" (e ovviamente il codice chiamante). –

Scusate, è assolutamente giusto, invece di flessibile e aperto che dovrebbe avere letto "visibile e diretto". Non sono sicuro di come chiameresti un servizio Web che passa in un tipo complesso tramite un URL, quindi questo mi ha influenzato leggermente. Ci sono degli svantaggi, lo rende più complesso? – Duncan

Si può andare nel modo più duro e mettere in atto l'opzione # 1, usando SOAP. Con SOAP è possibile definire tipi di dati complessi. D'altra parte, puoi farlo in modo "hack" come nell'opzione # 2, usando REST e codifica semplicemente i parametri nell'URL o nel messaggio HTTP POST.

fonte

2009-05-19 08:29:43 Dan

Il termine "servizio Web" viene spesso utilizzato per due cose diverse.

Una tecnologia: utilizzo di HTTP (S) come protocollo per la comunicazione tra processi.
Un approccio architettonico: Architettura orientata ai servizi.

Se stiamo parlando di web service come solo una tecnologia allora avete un sacco di opzioni: è possibile utilizzare HTTP GET (questa è quella che utilizza params URL) o HTTP POST (il dato è in corpo del messaggio HTTP). Per HTTP POST il payload può essere SOAP o semplicemente qualsiasi cosa appropriata.

Se stiamo parlando di un approccio orientato ai servizi e di servizi Web come uno strumento, HTTP + SOAP è la soluzione più standard.

Se consideriamo un metodo di servizio Web solo una realizzazione di un'operazione di servizio quindi utilizzare la firma in calce che sottolinea questo approccio:

public FooResponse FooOperation(FooRequest request);

Ciò significa che un'operazione ha una richiesta e un documento di risposta (anche se c'è ne di questi sono vuoti) e potete separare il contratto di servizio (che operazioni esponete) e il contratto di dati (come componi i messaggi di richiesta e risposta). Vedere questo articolo per ulteriori dettagli su di esso: Principles of Service Design Service Patterns and Anti-Patterns

Conclusione:

Se non si cura di SOA vogliono solo richiamare un metodo tramite HTTP, allora l'opzione 2 è chiara e semplice.
Ma se si stanno costruendo servizi SOA, utilizzare la firma "document-centric". L'opzione 1 è una combinazione di entrambi e non è raccomandata.

fonte

2009-05-19 09:23:18 Vizu

Grazie per questo, leggerò sicuramente le best practice SOA. Quando dici che è "sconsigliato" - non è ancora particolarmente brutto, vero ?! Per esempio, non vedo nulla in quel collegamento che lo descriva come Anti-Pattern. – Duncan

L'opzione 1 non è semplice come l'opzione 2 e non è disciplinata come la firma incentrata sul documento, ma non c'è nulla di male in essa. – Vizu

Opzione 1 stringa pubblica GetSomeData (criteri SomeCriteriaClass); è un buon modo per implementare il servizio web perché qui stai usando SOAP e il termine orientato al documento. E l'opzione2 è per gli sviluppatori Java di base che non si concentrano troppo sul modello di progettazione.

Prendiamo lo scenario - Dopo aver usato l'opzione 2, supponiamo di aggiungere 3 ulteriori varibale in SomeCriteriaClass.java, in che modo sceglierai .. aggiungi altri 3 parametri al metodo GetSomeData() o dichiari in SomeCriteriaClass.java.

Un buon follower modello di progettazione, scegliere di dichiarare in SomeCriteriaClass.java non aggiungere in GetSomeData().

fonte

2009-05-20 12:04:15

Grazie. Potresti darmi un esempio di come chiameresti un metodo usando Option1, tramite un URL? – Duncan

Interfaccia servizio Web - Tipo complesso come parametro?

risposta

Problemi correlati