Vor- und Nachteile von RESTful-Architektur [geschlossen]

Die häufigste Diskussion, die ich über die Vor- und Nachteile von REST gesehen habe, tendiert dazu, diese Diskussion in Bezug auf SOAP zu ordnen. Ich habe auch keine Erfahrung damit. Ich stehe derzeit vor einer Entscheidung, deren Bewertung mir aufgrund mangelnder Erfahrung schwer fällt. Ich beginne mit der Entwicklung einer Anwendung, die mehrere Komponenten enthält - hauptsächlich einen administrativen Aspekt, mit dem der Eigentümer mehrere Websites verwalten kann - und eine öffentlich zugängliche Benutzeroberfläche, mit der der Benutzer mit den auf dem Host gespeicherten Daten interagieren kann. Ich muss die Auswirkungen abwägen, die es mit sich bringt, dass der letzte Teil an einem beliebigen Ort gehostet werden kann und mit dem ersten Teil über eine REST-Architektur kommuniziert - oder dass beide Komponenten sich auf demselben Host befinden. Was sind die wichtigsten Auswirkungen der Entwicklung von RESTful-Architektur, insbesondere im Hinblick auf die Kapazität in den folgenden Bereichen:

1: Sicherheit 2: Leistung 3: Komplexität der Benutzeroberfläche

EDIT: Ein Blick auf einige der Antworten auf diese Frage - ich sollte klarstellen. Ich suche keinen Vergleich zu SOAP, sondern eine Übersicht über REST-Anwendungen im Vergleich zu Anwendungen, bei denen sich alle Komponenten auf einem Host befinden. (Danke für die Antworten!)

In diesen Bereichen kann ich einen groben Überblick geben, aber ich kann Ihre Schlussfolgerungen nicht für Sie ziehen. Es gibt zwei Hauptbereiche, in denen sich die beiden Protokolle unterscheiden:

• Nachrichtenformat
• Service-Erkennung

Das Nachrichtenformat ist am einfachsten zu verstehen. Das SOAP-Paket für Anforderungen und Antworten ist ziemlich schwer. Es gibt den SOAP-Umschlag, der sowohl einen Header- als auch einen Body-Abschnitt enthält. Der Header kann von mehreren Filtern in der Anforderungskette verwendet werden, um eine Art Identifikation, Autorisierung usw. durchzuführen. Die Analyse von XML ist jedoch teuer, was die Skalierbarkeit Ihres Systems in gewissem Maße beeinträchtigt. Wie viel davon abhängt, hängt von der SOAP-Verarbeitungsschicht in Ihrem Stapel ab.

Service Discovery ist der Ort, an dem Sie wahrscheinlich die meisten Konflikte haben werden. REST bietet von Natur aus vorhersehbare Endpunkte, und der Inhalt der Anforderung ist eine einfache HTTP-Anforderung. Der Vorteil ist, dass es keinen zusätzlichen Overhead gibt und Endbenutzer ziemlich genau raten können, was sie tun müssen, wenn sie die URL-Struktur Ihrer Website verstanden haben. Natürlich werden naive sicherheitsbewusste Menschen dies als Schwäche ansehen. Schließlich müssen Sie mit SOAP eine WSDL verwenden, um die Endpunkte zu ermitteln. Natürlich haben Sie mit SOAP das gesamte Nachrichtenformat erhalten, damit Sie gezielter angreifen können.

Aufgeschlüsselt nach den von Ihnen angegebenen Kategorien:

Sicherheit

Keiner ist von Natur aus sicherer als der andere. Verwenden Sie gute Sicherheitsgrundsätze:

• Verschlüsseln Sie die Kommunikation
• Stellen Sie vor der Verarbeitung sicher, dass Sie Benutzer authentifizieren und autorisieren
• Gute Codierungsgewohnheiten, um direkte Angriffe zu vermeiden
• Und das ist nur die kurze Liste.

Denken Sie an Dunkelheit! = Sicherheit.

Performance

Sowohl die Raw-Leistung als auch die Skalierbarkeit werden aufgrund der Anforderung nach einfachen HTTP-Protokollen an REST übergeben. Die meisten SOAP-Stacks verwenden SAX-Parsing (ereignisbasiertes Parsing), wodurch die Skalierbarkeit von SOAP-Stacks erheblich verbessert wird. Der Overhead ist jedoch messbar. SOAP hat zusätzlich zum XML-Parsing-Overhead den normalen HTTP-Verarbeitungs-Overhead. REST hat nur den HTTP-Verarbeitungsaufwand.

Komplexität

Aus Sicht des Systems gewinnt REST. Es gibt weniger bewegliche Teile, eine schlankere Anforderungskette usw. Das bedeutet, es ist einfacher, zuverlässig zu machen.

Aus Sicht des Programmierers kann SOAP gewinnen, wenn die von Ihnen verwendete IDE oder das von Ihnen verwendete Framework dies gut unterstützen. Im Wesentlichen müssen Sie mit REST die Vorverarbeitung (Authentifizierung / Autorisierung / usw.) durchführen, während mit SOAP ein Großteil davon mit einer steckbaren Verarbeitungskette ausgeführt werden kann.

Meine Vorliebe

Ich bin mit HTTP-Anfragen sehr vertraut und weiß, wie das Web funktioniert. Aus diesem Grund ist der REST-Ansatz für mich vorzuziehen. Ich weiß jedoch, dass sich einige meiner Kunden damit unwohl fühlen. Sie haben einige Artikel aus der Industrie gelesen, in denen die Sicherheit von REST im Vergleich zu SOAP usw. angeprangert wird. Unter dem Strich garantiert keiner der beiden Ansätze die Sicherheit. Sie müssen sicherstellen, dass die Anwendung so sicher ist, wie es sein muss. Offensichtlich verlangt (oder wünscht) eine Social Web-Anwendung nicht so viel Sicherheit wie ein Bank- oder Regierungssystem. Viele SOAP-Stacks enthalten Prozessoren, die Sie anschließen können, um ein gewisses Maß an Sicherheit zu gewährleisten. Es liegt jedoch weiterhin in Ihrer Verantwortung, diese zu suchen und zu installieren.

1. Sicherheit: Verwenden Sie HTTPS. Dies gilt für beide.
2. Performance: . REST ist weniger CPU-teuer (weniger Parsing, Marshalling, Unwrapping). Auch das Cachen mit REST ist ein Kinderspiel.
3. Komplexität: REST erfordert weniger Setup, es ist immerhin nur GET / POST. SOAP erfordert viel mehr Verwaltung (wsdl usw.), ist jedoch etwas einfacher, wenn Ihre IDE dies unterstützt.

Ich denke, SOAP ist viel zu aufgebläht, wenn Sie dasselbe mit REST und einigen Content- / Mime-Typen tun können. Außerdem bringt SOAP aufgrund seiner Wrapping-of-Wrapper-Natur und der Tatsache, dass es allgemeiner und nicht auf HTTP beschränkt ist, viel Overhead mit sich. SOAP ist in Versuchung, es zu verwenden, wenn Ihre IDE es ordnungsgemäß unterstützt und Sie HTTP nicht lernen möchten. Aber für mich ist REST viel einfacher zu bedienen und viel webfreundlicher.

Heutzutage gibt es sehr gute REST-APIs. Wenn Sie Java mögen, ist Jax-RS wirklich cool. Für einige Leute ist dies ist wie Porno.

Ich denke, der größte Vorteil von REST besteht darin, sich von RPC-Architekturen zu lösen. REST macht Ressourcen verfügbar, keine Prozesse. Auf diese Weise können Sie ein lose gebundenes System erstellen, bei dem Änderungen, Verbesserungen und sogar Ausfälle eines Teils nur begrenzte (negative) Auswirkungen auf andere Teile haben.

Leider besteht ein häufiger Missbrauch von REST darin, Ihre inneren Datenstrukturen freizulegen (im schlimmsten Fall handelt es sich um ein CRUD Ihrer Datenbank, ugh). Das macht es sehr schwer, es sicher zu machen. Die "richtige" Verwendung besteht darin, übergeordnete Objekte freizulegen, die für den Teil des Systems relevant sind, den Sie bearbeiten, und bei Inkonsistenzen Fehlerstatuscodes großzügig zurückzugeben.

Ein weiterer oft übersehener Teil von REST ist die Idempotenz der meisten Verben. Nicht nur GET, sondern auch PUT und DELETE sollten bei ein- oder mehrmaliger Anwendung genau dasselbe Ergebnis erzielen (Sie können keine 404 zurückgeben, wenn sie bereits gelöscht wurden, oder 'keine Änderung', wenn der Client dieselbe PUT-Anweisung ausführt). Dies führt zu robusten Systemen und einer geringeren Abhängigkeit der genauen Interpretation der Semantik.

Bei den WS- * -Standards geht es hauptsächlich darum, RPC über SOAP / HTTP auszuführen. Alle Überlegungen zu CORBA und J2EE sowie zu ihren Vorgängern haben sich daher darauf verlagert, in XML dasselbe zu tun. Dies bedeutet Dinge wie Typdeklarationen und Serviceverträge, Metadatenaustausch, deklarative Sicherheit usw. All das echte "unternehmerische" Zeug. Offen gesagt ist es sogar im Unternehmen überstrapaziert.

Personen, die eine Internet-Webanwendung wie Sie selbst erstellen, sollten mit ziemlicher Sicherheit eine RESTful-Architektur verwenden. Nahezu jede Plattform kann es nutzen und dies ganz einfach und ohne sich Gedanken darüber zu machen, welche Version welcher Spezifikation Sie verwenden, und ohne eine Vielzahl von werkzeugspezifischen Typkonvertierungsfehlern usw.

Der einzige große Vorteil von SOAP gegenüber den aktuellen REST-Implementierungen besteht darin, dass SOAP einfacher zu bearbeiten ist. Bei den meisten REST-Clients muss ich die Schnittstelle verstehen und einen Client schreiben. Für SOAP zeige ich einfach auf wsdl.exe und es generiert Klassen für mich.