In cosa differiscono nella pratica i servizi Web RESTful e SOAP?

Question

Sto implementando servizi Web per un'applicazione PHP e sto cercando di capire cosa offrono sia i servizi Web standard sia i servizi Web RESTful. Il mio intento è quello di scrivere il codice wrapper per sottrarre i dettagli del servizio Web in modo che gli sviluppatori possano semplicemente "istanziare oggetti remoti". e usali. Ecco i miei pensieri, forse alcuni di voi potrebbero aggiungere la vostra esperienza ed espandere questa:

Servizi Web RESTful

sono fondamentalmente solo "feed XML su richiesta", quindi ad es. potresti scrivere il codice wrapper per un'applicazione client in modo che possa interrogare l'applicazione server in questo modo:

$users = Users::getUsers("state = 'CO'");

• questo a sua volta otterrebbe un feed XML da un URL remoto
• $ utenti possono essere trasformati in una raccolta di oggetti utente completi, oppure
• lasciato come XML o
• trasformato in un array, ecc.
• lo script di query (" state = 'CO' ") verrebbe tradotto in SQL sul lato server

• I servizi Web RESTful sono in genere di sola lettura dalla vista del client, sebbene sia possibile scrivere codice che potrebbe utilizzare POST o GET per apportare modifiche al server, ad es. passando un token crittografato per motivi di sicurezza, ad esempio:

  $ users = Users :: addUser ($cryptedTrustToken, 'jim', $cryptedPassword, 'James', 'Taylor');

e questo creerebbe un nuovo utente nell'applicazione server.

Servizi Web standard

I servizi Web standard alla fine fanno sostanzialmente la stessa cosa. L'unico vantaggio che hanno è che il cliente può scoprire i propri dettagli tramite WSDL. Ma a parte questo, se voglio scrivere codice wrapper che consenta a uno sviluppatore di creare un'istanza, modificare e salvare oggetti da remoto, devo comunque implementare il codice wrapper. SOAP non fa nulla di tutto ciò per me, può farlo:

$soap = new nusoap_client('http://localhost/test/webservice_user.php?wsdl', true);
$user = $soap->getProxy(); 
$lastName = $user->lastName();

ma se voglio modificare e salvare:

$user->setLastName('Jones');
$user->save();

quindi devo ad es. gestire tutto lo stato sul lato server, SOAP non sembra contenere quell'oggetto sul lato server per ciascun client.

Forse ci sono delle limitazioni nell'implementazione di PHP SOAP che sto usando (nusoap). Forse le implementazioni Java e .NET fanno molto di più.

Sarà un piacere ascoltare il tuo feedback per chiarire alcune di queste nuvole.

Answer 1

Sono modelli diversi ... REST è incentrato sui dati , dove SOAP è incentrato sull'operazione . vale a dire con SOAP si tende ad avere operazioni discrete " SubmitOrder " ;, ecc .; ma con REST sei in genere molto più fluido su come stai interrogando i dati.

SOAP tende anche ad essere associato a molta più complessità (che a volte è necessario) - REST è tornato a POX ecc. e YAGNI .

---

In termini di .NET, strumenti come " wsdl.exe " ti fornirà una libreria proxy lato client completa per rappresentare un servizio SOAP (o "svcutil.exe" per un servizio WCF):

var someResult = proxy.SubmitOrder(...);

Per REST con .NET, credo che ADO.NET Data Services sia il player più ovvio. Qui, gli strumenti (datasvcutil.exe) forniranno un contesto dati completo sul lato client con supporto LINQ. LINQ è il modo relativamente nuovo di .NET di formare query complesse. Quindi qualcosa del tipo (con controllo del tipo forte / statico e intellisense):

var qry = from user in ctx.Users
          where user.State == 'CO'
          select user;

(questo verrà tradotto nella / dalla sintassi REST appropriata per ADO.NET Data Services)

Answer 2

Sto facendo eco a ciò che ha detto Marc Gravell. Quando le persone mi chiedono di REST (e di solito hanno un'idea di SOAP e SOA), dirò loro REST = ROA poiché è orientato alle risorse / ai dati, è un paradigma diverso e quindi ha diversi problemi di progettazione.

Per il tuo caso, se ti sto leggendo correttamente, vuoi evitare di scrivere il codice wrapper e hai bisogno di una soluzione in grado di archiviare oggetti e i loro attributi in remoto (e di averli completamente nascosti agli sviluppatori). Non posso davvero suggerire una soluzione migliore. Umm, fammi sapere se uno di questi si avvicina mai per soddisfare le tue esigenze:

1. EJB3 / JPA
2. CouchDB (REST / JSON)

Fammi sapere anche se ho interpretato la tua domanda in modo errato.

Se confrontiamo XML-RPC e SOAP, quest'ultimo ti fornirà una migliore gestione dei tipi di dati, per il primo sebbene tu abbia a che fare con tipi di dati più semplici ma dovrai scrivere un livello o un adattatore per convertirli nel tuo dominio oggetti.

YC

Answer 3

Il sapone è solo un insieme di schemi XML concordati benedetti da un gruppo di standard. Il suo punto di forza è che è stato progettato per l'interoperabilità e supporta molte funzionalità di classe enterprise. Il sapone su qualsiasi piattaforma non fornirà le operazioni che stai cercando. Devi progettare & amp; implementare il contratto di servizio per ottenere tali funzionalità.

Sembra che tu voglia oggetti remoti per i quali né Soap né REST sono particolarmente adatti. Forse sarebbe meglio guardare XML-RPC .

Answer 4

Le differenze chiave sono sostanzialmente gli strumenti.

Molte delle pile SOAP di fascia alta avvolgono la maggior parte dell'infrastruttura SOAP dallo sviluppatore, dove lavori praticamente esclusivamente con DTO / Documents and RPC.

REST su HTTP comporta un maggior onere per lo sviluppatore (negoziazione dei formati [XML, JSON, HTTP POST], analisi dei risultati [DOM, mappe, marshalling DTO, ecc.]).

Ovviamente, puoi scrivere un livello logico per semplificare la gestione di questi dettagli. E alcuni framework REST sono arrivati ??per renderlo più semplice, ma al momento è ancora un compito nel tuo elenco TODO quando desideri utilizzare o utilizzare tali servizi.

Answer 5

Il mio feedback è che se vuoi lo stato remoto, non stai parlando di servizi web. Non conosco alcun modello contemporaneo che affronti lo stato remoto. Penso che se hai bisogno di uno stato remoto sei da solo (senza religione da seguire). Basta lanciare xml da qui a lì e non preoccuparti della teoria.

Devo aggiungere che lo stato remoto è malvagio. Evitalo se puoi.