Rest gegen Seife. Hat REST eine bessere Leistung?

Question

Ich lese einige Fragen, die bereits hier bezüglich Soap and Rest geschrieben wurden, und ich fand die Antwort nicht, die ich suche. Wir haben ein System, das mit Soap-Web-Services erstellt wurde. Das System ist nicht sehr leistungsfähig und es wird diskutiert, alle Soap-Webdienste für REST-Webdienste zu ersetzen. Jemand hat argumentiert, dass Ruhe eine bessere Leistung hat. Ich weiß nicht, ob das stimmt. (Dies war meine erste Frage) Angenommen, dies ist wahr, gibt es einen Nachteil mit REST anstelle von Soap? (Verlieren wir etwas?)

Vielen Dank im Voraus.

Answer 1

Leistung ist breites Thema.

Wenn Sie die Last des Servers meinen, hat REST eine etwas bessere Leistung, da es neben HTTP nur minimalen Overhead verursacht. Normalerweise bringt SOAP einen Stapel verschiedener (generierter) Handler und Parser mit. Wie dem auch sei, der Leistungsunterschied selbst ist nicht so groß, aber RESTful Service ist einfacher zu 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. Also, wenn Ihr Dienst sowieso über HTTP läuft, können Sie nicht viel schlanker als REST bekommen. Wenn Sie Ihre Repräsentationen in JSON (im Gegensatz zu XML) codieren, sparen Sie außerdem viel mehr Bytes.

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

jedoch einige Dinge zu beachten, (da Sie gefragt, ‚was Sie verlieren?‘):

RESTful Schnittstellen sind in der Regel ein bisschen mehr „gesprächig“ sein, also auf Ihrer Domain abhängig und wie Sie entwerfen Sie Ihre Ressourcen, können Sie am Ende mehr HTTP-Anfragen ausführen.

SOAP hat eine sehr breite Werkzeugunterstützung. Zum Beispiel, Berater lieben es, weil sie Tools verwenden können, um die Schnittstelle zu definieren und generieren die WSDL-Datei und Entwickler lieben es, weil sie eine andere Reihe von Tools verwenden können, um den gesamten Netzwerkcode aus dieser WSDL-Datei zu generieren. Außerdem hat XML als Repräsentation Schemata und Validatoren, die in einigen Fällen ein Schlüsselproblem darstellen können. (JSON und REST haben ähnliche Sachen kommen aber die Tool-Unterstützung ist weit hinter)

Answer 2

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

Ich bin sicher, es gibt auch andere ppl hier SO auf, die Sie besser und detaillierte Antworten geben kann, aber zumindest habe ich versucht;)

Answer 3

SOAP erfordert eine XML-Nachricht analysiert werden und dass alle < riduculouslylongnamespace: mylongtagname> extra </riducouslylongnamespace: mylongtagname> zu sendende und empfangene Sachen.

REST verwendet normalerweise etwas viel knapper und einfach zu analysierendes JSON.

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

Das Erstellen eines DOM aus XML ist normalerweise ein superschnelles, superoptimiertes Stück Code wie XERCES in C++ oder Java, während die meisten JSON Parser in der Rolle Ihre eigene oder interpretierte Kategorie sind.

In einer schnellen Netzwerkumgebung (LAN oder Breitband) gibt es keinen großen Unterschied zwischen dem Senden von einem oder zwei K im Vergleich zu 10 bis 15 k.

Answer 4

Nur um ein wenig zu Wuhers Antwort hinzuzufügen.

Http-Header-Bytes, wenn diese Seite Anfordern des Chrome Web-Browser: 761
Bytes für die Probe Seife Nachricht erforderlich in wikipedia Artikeln: 299

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

Es ist sehr unwahrscheinlich, dass die einfache Umwandlung eines SOAP-Dienstes in REST signifikante Leistungsvorteile bringt. Der Vorteil von REST besteht darin, dass Sie, wenn Sie den Einschränkungen folgen, die Mechanismen nutzen können, die HTTP für die Produktion skalierbarer Systeme bietet. Caching und Partitionierung sind die Werkzeuge in deinem Toolbelt.

Answer 5

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

Wenn Sie SOAP (eine Technologie) verwenden, haben Sie normalerweise ein System, das in 'Methoden' definiert ist, da Sie mit RPC arbeiten.

Wenn Sie REST (ein Architekturstil, keine Technologie) verwenden, erstellen Sie ein System, das als "Ressourcen" und nicht als Methoden definiert ist. Es gibt kein 1: 1-Mapping zwischen SOAP und REST. Die Systemarchitektur ist grundlegend anders.

Oder sprechen Sie nur von "RPC über URI", was oft mit REST verwechselt wird?

Answer 6

Es hängt alles ab. REST hat nicht wirklich eine (gute) Antwort für die Situation, in der die Anfragedaten groß werden können. Ich spüre diesen Punkt, wenn er beim RESTHüpfen manchmal übersehen wird.

Stellen wir uns einen Dienst vor, mit dem Sie Informationsdaten für tausende verschiedene Artikel anfordern können.

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

Der REST-Entwickler wäre besorgt, dass sein 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 für jedes Element aufrufen, um Ihre Daten zu erhalten. Sauber und einfach zu verstehen ... aber.

In diesem Fall wären wesentlich mehr Round-Trips erforderlich, damit der REST-Dienst die mit einem einzigen Aufruf des SOAP-Dienstes möglichen Aktionen ausführen kann.

Ja, ich weiß, es gibt Problemumgehungen für die Verarbeitung großer Anforderungsdaten im REST-Szenario. Zum Beispiel können Sie Sachen in den Körper Ihrer Anfrage packen. Aber dann müssen Sie sorgfältig definieren (sowohl auf der Server- als auch auf der Client-Seite), wie dies zu interpretieren ist. In diesen Situationen empfinden Sie den Schmerz, dass REST nicht wirklich ein Standard ist (wie SOAP), sondern eher eine Art, Dinge zu tun.

Für Situationen, in denen nur relativ begrenzte Datenmengen ausgetauscht werden, ist REST eine sehr gute Wahl. Am Ende des Tages ist dies die Mehrzahl der Anwendungsfälle.

Answer 7

Eines der anderen Antworten scheint die REST-Unterstützung für Caching und andere Vorteile von HTTP zu übersehen. Während SOAP HTTP verwendet, nutzt es die unterstützende Infrastruktur von HTTP nicht. Die SOAP 1.1-Bindung definiert nur die Verwendung des POST-Verbs. Dies wurde mit der Einführung von GET-Bindungen mit der Version 1.2 behoben, dies kann jedoch ein Problem sein, wenn die ältere Version verwendet wird oder die entsprechenden Bindungen nicht verwendet werden.

Sicherheit ist ein weiterer wichtiger Leistungsaspekt. REST-Anwendungen verwenden in der Regel TLS oder andere Sicherheitsmechanismen der Sitzungsschicht. TLS ist viel schneller als die Verwendung von Sicherheitsmechanismen auf Anwendungsebene wie WS-Sicherheit (WS-Sicherheit leidet auch unter security flaws).

Ich denke jedoch, dass dies meist kleinere Probleme beim Vergleich von SOAP und REST-basierten Diensten sind. Sie können Arbeitsumgebungen für die Leistungsprobleme von SOAPs oder REST finden. Meine persönliche Meinung ist, dass weder SOAP noch REST (bei REST meine ich HTTP-basierte REST-Dienste) für Dienste geeignet sind, die hohen Durchsatz und geringe Latenzzeiten erfordern. Für diese Art von Diensten möchten Sie wahrscheinlich mit Apache Thrift, 0MQ oder den unzähligen anderen binären RPC-Protokollen arbeiten.

Answer 8

Im Allgemeinen wird ein REST-basierter 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 die Sicherheit und die Zuverlässigkeit der Transaktionen erfordert.

Die Antwort hängt wirklich von den funktionalen und nicht-funktionalen Anforderungen ab. Die folgenden Fragen helfen Ihnen bei der Auswahl.

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

wird der Dienst aussetzen Daten oder Geschäftslogik? (REST ist eine bessere Wahl für das Aussetzen von Daten, SOAP WS könnte eine bessere Wahl für die Logik sein). Erfordern die Verbraucher und die Dienstleister einen formellen Vertrag? (SOAP hat einen formellen Vertrag über WSDL) Müssen wir mehrere Datenformate unterstützen? Müssen wir AJAX-Anrufe tätigen? (REST kann den XMLHttpRequest verwenden) Ist der Aufruf synchron oder asynchron? Ist der Anruf status- oder zustandslos? (REST ist für statusfreie CRUD-Operationen geeignet) Welche Sicherheitsstufe ist erforderlich? (SOAP WS bietet bessere Unterstützung für die Sicherheit) Welche Unterstützungsebene für Transaktionen ist erforderlich? (SOAP WS hat eine bessere Unterstützung für das Transaktionsmanagement) Haben wir eine begrenzte Bandbreite? (SOAP ist ausführlicher) Was ist das Beste für die Entwickler, die Clients für den Service erstellen? (REST ist einfacher zu implementieren, zu testen und zu warten)

Answer 9

Sie müssen nicht die Wahl treffen, moderne Frameworks ermöglichen es Ihnen, Daten in diesen Formaten mit einer minimalen Änderung verfügbar zu machen. Befolgen Sie Ihre Geschäftsanforderungen und testen Sie die spezifische Implementierung, um den Durchsatz zu verstehen. Es gibt keine korrekte Antwort auf diese Frage ohne den richtigen Auslastungstest eines bestimmten Systems.