Unterschied zwischen REST und WebServices

Question

Was ist der Unterschied zwischen REST und WebService (SOAP), ich schaute auf die Facebook API, sie verwenden HTTP-Header und einige Parameter (wahrscheinlich XML oder nicht) und Ergebnis in XML, wo sonst SOAP genau Gleiches, HTTP-Header + XML-Parameter und gibt Header + XML zurück.

REST erfordert auch einige authentifizierte Token, wo sonst SOAP HTTP-Sitzung verwendet, die genau dasselbe Token für Auth und andere Informationen verwendet wird. Alles was ich sehen kann ist, dass SOAP eine kleine erweiterte Version von REST ist?

Oder gibt es andere Leistungsüberlegungen? Das Lesen von REST spricht nur eine sehr hohe Ebene der Client-Server-Kommunikation, aber auch SOAP tut genau dasselbe. Kann mir jemand zeigen, wo es die richtige Grenze von REST und SOAP definieren kann.

Wir verwenden viele SOAP transparent in .net, aber ich möchte nur wissen, ist es wirklich wert, die Aufmerksamkeit auf REST zu zahlen, wo derzeit alles läuft hervorragend glatt.

Ich weiß, REST ist eine Architektur und SOAP ist ein Protokoll, aber meine Frage ist im Detail, das ist derzeit die ASP.NET WebService-Implementierung von SOAP hat REST-Architektur?

Answer 1

SOAP ist ein Protokoll zum Senden/Empfangen von Daten über HTTP als XML.

Ein typischer WebService wird ein paar Methoden eine WSDL, die beschreibt, wie es aufgerufen wird. Es gibt keine echte Konvention dafür, wie diese strukturiert sein sollten. Daher benötigen Sie immer eine Menge API-Dokumentation.

Typischerweise wird dies so etwas wie (für ASP.NET):

• HTTP POST-mysite.com/products.asmx/ListAllProducts - kehrt XML Liste der Produkte
• HTTP POST-mysite.com/products.asmx/GetProduct - gibt XML für Produkt basierend auf SOAP XML im veröffentlichten Inhalt zurück
• HTTP POST bis mysite.com/products.asmx/UpdatePr oduct - ändert Produkt auf Basis von SOAP XML in dem von ihm entsandten Inhalt

REST mehr eine Konvention ist für alle Ihre Methoden zu strukturieren:

• HTTP GET von mysite.com/products - Rückkehr XML oder JSON Auflistung aller Produkte
• HTTP GET von mysite.com/products/14 - gibt XML oder JSON für das Produkt 14
• HTTP POST bis mysite.com/products/14 - Ändert Produkt 14 zu dem, was Sie im HTML-Formular veröffentlichen.
• HTTP DELETE-mysite.com/products/14 - entfernt 14 Produkt
• HTTP PUT-mysite.com/products - Fügt ein neues Produkt hinzu

So funktioniert REST mehr wie Sie Browser-URLs erwarten würden. Auf diese Weise ist es natürlicher und eine Konvention ist viel einfacher zu verstehen. Alle REST-APIs arbeiten auf ähnliche Weise, sodass Sie nicht so viel Zeit mit dem Erlernen der Eigenheiten jedes Systems verbringen müssen.

Answer 2

Für mich gewinnt ein Service, der mit einem RESTful-Ansatz implementiert wurde, einen, der SOAP oder RPC hinsichtlich seiner Zugänglichkeit verwendet. In einem relativ geschlossenen System, in dem Tools zur Generierung von Stubs und Verbindungen auf Basis einer WSDL verfügbar sind, ist dies nicht besonders wichtig. Wenn Sie jedoch Dienste erstellen möchten, die für eine breite Palette von Clients zugänglich und verfügbar sind, ist die Einheitlichkeit der REST-Services und die Leichtigkeit, mit der sie genutzt werden können, ein großes Plus, dh Sie benötigen keinen schweren RPC-Stack die Möglichkeit, HTTP-Anfragen zu stellen.

Nicht sicher, dass dies Ihre Frage vollständig beantwortet, aber wenn, wie Sie sagen, Sie ein System haben, das auf SOAP funktioniert (und Sie den Client und Server steuern), sehe ich keinen Grund zu ändern. Außerdem bieten sich einige Dienste natürlich eher für RPC-basierten Zugriff an, in welchem ​​Fall eine SOAP-Schnittstelle geeigneter ist.

In Bezug auf die Leistung, eine oder mehrere Schichten würden effektiv aus den Client-und Server-Technologie-Stacks entfernt werden, wenn Sie nicht SOAP verwenden, so dass alle anderen Dinge gleich, ein Dienst, der eine RESTful-Schnittstelle exponiert wird dort gewinnen.