wake-up-neo.com

Rest vs. Seife. Hat REST eine bessere Leistung?

Ich habe einige Fragen zu Soap and Rest gelesen, die hier bereits gepostet wurden. Ich habe die Antwort nicht gefunden, die ich suche ... Wir haben ein System, das mit Soap-Webservices erstellt wurde. Das System ist nicht verfügbar Sehr performant und es ist in Diskussion, um alle Soap-Webdienste für REST - Webdienste zu ersetzen ..__ Jemand hat behauptet, dass Rest eine bessere Leistung hat . Ich weiß nicht, ob das stimmt . (Dies war meine erste Frage) Wenn dies angenommen wird, gibt es einen Nachteil, wenn REST anstelle von Soap verwendet wird? (Verlieren wir etwas?)

Danke im Voraus.

30
Luixv

Leistung ist ein weites Thema. 

Wenn Sie die Belastung des Servers meinen, hat REST eine etwas bessere Leistung, da sie einen minimalen Overhead auf HTTP verursacht. Normalerweise bringt SOAP einen Stapel unterschiedlicher (generierter) Handler und Parser mit sich. Der Leistungsunterschied selbst ist zwar nicht so groß, aber der RESTful-Service lässt sich einfacher skalieren, da Sie keine serverseitigen Sitzungen haben.

Wenn Sie die Leistung des Netzwerks (d. H. Bandbreite) meinen, hat REST eine viel bessere Leistung. Im Grunde ist es nur HTTP. Kein Aufwand Wenn Ihr Dienst ohnehin auf HTTP läuft, können Sie nicht viel schlanker sein als REST. Wenn Sie Ihre Repräsentationen in JSON (im Gegensatz zu XML) kodieren, sparen Sie außerdem viel mehr Bytes.

Kurz gesagt, ich würde "Ja" sagen, mit REST werden Sie leistungsfähiger. Außerdem wird (meiner Meinung nach) Ihre Benutzeroberfläche einfacher für Ihre Kunden verwendet. So wird nicht nur Ihr Server schlanker, sondern auch der Client. 

Es gibt jedoch ein paar Dinge zu beachten (da Sie gefragt haben, "Was werden Sie verlieren?"):

REST-fähige Schnittstellen sind in der Regel etwas "gesprächiger". Abhängig von Ihrer Domäne und wie Sie Ihre Ressourcen entwerfen, werden Sie möglicherweise mehr HTTP-Anforderungen ausführen.

SOAP bietet eine sehr breite Werkzeugunterstützung. Berater lieben es zum Beispiel, weil sie Tools zum Definieren der Schnittstelle und zum Erzeugen der WSDL-Datei verwenden können, und Entwickler lieben es, weil sie andere Tools verwenden können, um den gesamten Netzwerkcode aus dieser WSDL-Datei zu generieren. Darüber hinaus enthält XML als Repräsentation Schemata und Validatoren, die in einigen Fällen ein Schlüsselproblem sein können. (JSON und REST haben zwar schon ähnliche Sachen, aber die Werkzeugunterstützung liegt weit zurück)

46
wuher

SOAP erfordert, dass eine XML-Nachricht analysiert wird, und all das, was überflüssig für einen langen Namespace: mylongtagname> extra </ riduculouslylongnamespace: mylongtagname> vorhanden ist, wird gesendet und empfangen.

REST verwendet normalerweise etwas viel knapperes und einfach zu analysierendes Verhalten wie JSON.

In der Praxis ist der Unterschied jedoch nicht so groß. 

Beim Erstellen eines DOM aus XML wird normalerweise ein superschneller, superoptimierter Code wie XERCES in C++ oder Java erstellt, während die meisten JSON-Parser Ihre eigene oder interpretierte Kategorie darstellen.

In schnellen Netzwerkumgebungen (LAN oder Breitband) besteht kein großer Unterschied zwischen dem Senden von ein oder zwei K gegenüber 10 bis 15 K. 

14
James Anderson

Sie formulieren die Frage so, als ob REST und SOAP in einem vorhandenen System irgendwie austauschbar wären. Sie sind nicht.

Wenn Sie SOAP (eine Technologie) verwenden, haben Sie normalerweise ein System, das in "Methoden" definiert ist, da Sie sich tatsächlich mit RPC beschäftigen.

Wenn Sie REST (einen Architekturstil, keine Technologie) verwenden, erstellen Sie ein System, das in Form von "Ressourcen" und nicht in Methoden definiert ist. Es gibt keine 1: 1-Zuordnung zwischen SOAP und REST. Die Systemarchitektur unterscheidet sich grundlegend.

Oder sprichst du nur über "RPC via URI", das oft mit REST verwechselt wird?

10
jbrendel

Was die anderen Antworten zu übersehen scheinen, ist die Unterstützung von REST für das Caching und andere Vorteile von HTTP. Während SOAP HTTP verwendet, wird die unterstützende Infrastruktur von HTTP nicht genutzt. Die Bindung SOAP 1.1 definiert nur die Verwendung des Verbs POST. Dieses Problem wurde in Version 1.2 mit der Einführung von GET-Bindungen behoben. Dies kann jedoch ein Problem sein, wenn Sie die ältere Version verwenden oder nicht die entsprechenden Bindungen verwenden. 

Sicherheit ist ein weiterer wichtiger Aspekt der Leistung. REST - Anwendungen verwenden normalerweise TLS oder andere Sicherheitsmechanismen auf Sitzungsschicht. TLS ist viel schneller als die Verwendung von Sicherheitsmechanismen auf Anwendungsebene wie WS Security (WS Security leidet auch an Sicherheitslücken ). 

Ich denke jedoch, dass dies beim Vergleichen von SOAP - und REST -basierten Diensten meist nur geringfügige Probleme sind. Sie können Umgehungen für die Leistungsprobleme von SOAP oder REST finden. Meine persönliche Meinung ist, dass weder SOAP noch REST (von REST: HTTP-basierte REST - Dienste) für Dienste geeignet sind, die einen hohen Durchsatz und niedrige Latenz erfordern. Für diese Arten von Diensten möchten Sie wahrscheinlich etwas wie Apache Thrift, 0MQ oder die Vielzahl anderer binärer RPC-Protokolle verwenden. 

5
Shawn H

Nur um ein wenig zur Antwort hinzuzufügen.

HTTP-Header-Bytes beim Anfordern dieser Seite mit dem Chrome-Webbrowser: 761
Bytes, die für die Beispielseifennachricht in wikipedia article: 299 erforderlich sind 

Mein Fazit: Es ist nicht die Größe von Bytes auf dem Draht, die eine gute Leistung von REST ermöglicht.

Es ist höchst unwahrscheinlich, dass die Umstellung eines SOAP -Dienstes auf REST signifikante Leistungsvorteile bringt. Der Vorteil von REST besteht darin, dass Sie die von HTTP bereitgestellten Mechanismen zur Erstellung skalierbarer Systeme nutzen können, wenn Sie den Einschränkungen folgen. Caching und Partitionierung sind die Werkzeuge in Ihrem Toolbelt.

4
Darrel Miller

Ich bin definitiv kein Experte, wenn es um SOAP im Vergleich zu REST geht, aber der einzige Leistungsunterschied, den ich kenne, ist, dass SOAP viel Aufwand beim Senden/Empfangen von Paketen verursacht, da es XML-basiert ist Ein SOAP -Header usw. REST verwendet die URL + Abfragestring, um eine Anfrage zu stellen, und sendet daher nicht so viele kB über die Leitung.

Ich bin sicher, es gibt andere Leute hier auf SO, die Ihnen bessere und detailliertere Antworten geben können, aber ich habe es zumindest versucht;)

4
KBoek

Es hängt alles ab. REST hat nicht wirklich eine (gute) Antwort auf die Situation, in der die Anfragedaten groß werden können. Ich fühle diesen Punkt, wenn ich manchmal den REST überspringe.

Stellen wir uns einen Dienst vor, mit dem Sie Informationsdaten für Tausende verschiedener Elemente anfordern können.

Der SOAP Entwickler würde eine Methode definieren, mit der Sie die Informationen für ein oder beliebig viele Elemente abrufen können ... in einem einzigen Aufruf.

Der REST Entwickler wäre besorgt, dass seine URI zu lang werden würde, sodass er eine GET-Methode definieren würde, die ein einzelnes Element als Parameter verwenden würde. Sie müssten dies dann mehrmals aufrufen, einmal für jeden Artikel, um Ihre Daten zu erhalten. Sauber und einfach zu verstehen ... aber.

In diesem Fall wären für den REST Dienst wesentlich mehr Roundtrips erforderlich, um zu erreichen, was mit einem einzigen Aufruf des SOAP Dienstes erreicht werden kann.

Ja, ich weiß, dass es im Szenario REST Workarounds gibt, wie mit großen Anforderungsdaten umgegangen wird. Zum Beispiel können Sie Sachen in den Körper Ihrer Anfrage packen. Dann müssen Sie jedoch (sowohl auf der Server- als auch auf der Clientseite) sorgfältig definieren, wie dies zu interpretieren ist. In diesen Situationen fühlt man den Schmerz, der REST nicht wirklich ein Standard ist (wie SOAP), sondern eher eine Art, Dinge zu tun.

In Situationen, in denen nur eine relativ begrenzte Datenmenge ausgetauscht wird REST ist dies eine sehr gute Wahl. Am Ende des Tages sind dies die meisten Anwendungsfälle.

3
peterh

Im Allgemeinen wird ein auf REST basierender Webdienst aufgrund seiner Einfachheit, Leistung, Skalierbarkeit und Unterstützung für mehrere Datenformate bevorzugt. SOAP wird bevorzugt, wenn der Service umfassende Unterstützung für Sicherheit und Transaktionszuverlässigkeit erfordert.

Die Antwort hängt wirklich von den funktionalen und nicht funktionalen Anforderungen ab. Wenn Sie die unten aufgeführten Fragen stellen, können Sie sich entscheiden.

REf: http://Java-success.blogspot.ca/2012/02/Java-web-services-interview-questions.html

Stellt der Dienst Daten oder Geschäftslogik bereit? (REST ist eine bessere Wahl für die Offenlegung von Daten, SOAP WS ist möglicherweise die bessere Wahl für die Logik.) . Benötigen die Verbraucher und die Diensteanbieter einen förmlichen Vertrag? (SOAP hat einen formalen Vertrag über WSDL.) Müssen wir mehrere Datenformate unterstützen? Müssen wir AJAX - Aufrufe machen? (REST kann XMLHttpRequest verwenden.) Ist der Anruf synchron oder asynchron? Ist der Anruf zustandsbehaftet oder zustandslos? (REST ist für statlose CRUD-Vorgänge geeignet.) Welche Sicherheitsstufe ist erforderlich? (SOAP WS bietet bessere Sicherheitsunterstützung) Welches Maß an Transaktionsunterstützung ist erforderlich? (SOAP WS bietet eine bessere Unterstützung für das Transaktionsmanagement.) Haben wir eine begrenzte Bandbreite? (SOAP ist ausführlicher). Was ist für Entwickler am besten, die Clients für den Dienst erstellen werden? (REST ist einfacher zu implementieren, zu testen und zu warten)

Sie müssen sich nicht entscheiden, moderne Rahmen ermöglichen es Ihnen, Daten in diesen Formaten mit einer minimalen Änderung bereitzustellen. Folgen Sie Ihren geschäftlichen Anforderungen und testen Sie die spezifische Implementierung mit Last, um den Durchsatz zu verstehen. Diese Frage ist ohne die richtige Lastprüfung eines bestimmten Systems nicht richtig beantwortet.

0
serg.nechaev