Differenza tra REST e WebServices

Question

Qual è la differenza tra REST e WebService (SOAP), ho guardato l'API di facebook, usano le intestazioni HTTP e alcuni parametri (probabilmente xml o non) e restituiscono il risultato in xml, dove altrimenti SOAP fa esattamente stesso, intestazioni HTTP + parametri xml e restituisce intestazioni + xml.

REST richiede anche un token autenticato in cui altrimenti SOAP utilizza la sessione http che è esattamente lo stesso token utilizzato per l'autenticazione e altre informazioni. Tutto quello che posso vedere è che SOAP è una versione poco avanzata di REST?

Oppure ci sono altre considerazioni sulle prestazioni? La lettura di REST parla solo di un livello molto alto di comunicazione con i client server, ma anche SOAP fa esattamente lo stesso. Qualcuno può indicarmi dove può definire il corretto numero di REST e SOAP.

Usiamo molto SOAP in modo trasparente in .net, tuttavia voglio solo sapere che vale veramente la pena di prestare attenzione a REST dove attualmente tutto è in esecuzione straordinariamente scorrevole.

So che REST è un'architettura e SOAP è un protocollo ma la mia domanda è nel dettaglio che attualmente l'implementazione ASP.NET WebService di SOAP ha un'architettura REST?

Answer 1

SOAP è un protocollo per l'invio/ricezione di dati su HTTP come XML.

Un tipico servizio Web sarà costituito da alcuni metodi un WSDL che descrive come chiamarlo. Non esiste una vera convenzione per come dovrebbero essere strutturati, quindi hai sempre bisogno di molta documentazione API.

In genere questo sarà qualcosa di simile (per ASP.NET):

• HTTP POST a mysite.com/products.asmx/ListAllProducts - torna elenco XML dei prodotti
• HTTP POST-mysite.com/products.asmx/GetProduct - restituisce XML per prodotto basato su XML SOAP nel contenuto pubblicato
• HTTP POST a mysite.com/products.asmx/UpdatePr oduct - modifiche di prodotto basata su XML SOAP nel contenuto pubblicato

REST è più di una convenzione per la strutturazione di tutti i metodi:

• HTTP GET da mysite.com/products - rendimenti XML o JSON messa in vendita di tutti i prodotti
• HTTP GET da mysite.com/products/14 - restituisce XML o JSON per il prodotto 14
• HTTP POST a mysite.com/products/14 - modifica il prodotto 14 a ciò che pubblichi nel modulo HTML.
• HTTP DELETE-mysite.com/products/14 - rimuove prodotto 14
• HTTP PUT-mysite.com/prodotti - aggiunge un nuovo prodotto

Così REST funziona più come ci si aspetterebbe URL del browser a. In questo modo è più naturale e una convenzione è molto più facile da capire. Tutte le API REST funzionano in modo simile, quindi non si spende quanto a lungo le peculiarità di ciascun sistema.

Answer 2

Per me un servizio implementato utilizzando un approccio RESTful vince su uno che utilizza SOAP o RPC in termini di accessibilità. In un sistema relativamente chiuso in cui gli strumenti sono disponibili per generare stub e legami basati su un WSDL, questo non è molto importante. Tuttavia, se si desidera creare servizi accessibili e disponibili per una vasta gamma di client, l'uniformità dei servizi REST e la facilità con cui possono essere consumati è un grande vantaggio, ovvero non è necessario un grosso stack RPC, solo la capacità di fare richieste HTTP.

Non sono sicuro che questo risponda totalmente alla tua domanda, ma se, come dici tu, hai un sistema che funziona basato su SOAP (e controlli il client e il server), allora non vedo alcun motivo per cambiare. Inoltre, alcuni servizi si presteranno naturalmente a un accesso basato su RPC, nel qual caso un'interfaccia SOAP sarà più appropriata.

In termini di prestazioni, uno o più livelli verrebbero effettivamente rimossi dagli stack di tecnologia client e server se non si utilizza SOAP, quindi a parità di condizioni, un servizio che espone un'interfaccia RESTful vincerà lì.