it-swarm-eu.dev

Vor- und Nachteile einer RESTful-Architektur

Die häufigste Diskussion, die ich über die Vor- und Nachteile von REST) gesehen habe, tendiert dazu, diese Diskussion in Bezug auf SOAP zu gestalten. Ich habe auch keine Erfahrung damit. Ich stehe derzeit vor einer Entscheidung, die mir fehlt Die Erfahrung macht es mir schwer zu bewerten. Ich beginne mit der Entwicklung einer Anwendung mit mehreren Komponenten - hauptsächlich einem administrativen Aspekt, mit dem der Eigentümer mehrere Websites verwalten kann - und einer öffentlich zugänglichen Benutzeroberfläche, über die der Benutzer mit den gespeicherten Daten interagieren kann auf dem Host. Ich muss die Auswirkungen bewerten, die sich daraus ergeben, dass der letztere Teil überall gehostet werden und über eine RESTful-Architektur mit dem ersteren kommunizieren kann - oder verlangen, dass sich beide Komponenten auf demselben Host befinden. Was sind die wichtigsten Auswirkungen der Entwicklung einer RESTful-Architektur? insbesondere im Hinblick auf die Kapazität in folgenden Bereichen:

1: Sicherheit 2: Leistung 3: Schnittstellenkomplexität

EDIT: Wenn ich mir einige Antworten auf diese Frage ansehe, sollte ich das klarstellen. Ich suche keinen Vergleich mit SOAP - eher eine Übersicht über REST Anwendungen gegen Anwendungen, bei denen sich alle Komponenten auf einem Host befinden (danke für diese Antworten) obwohl!)

20
sunwukung

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
  • Serviceerkennung

Das Nachrichtenformat ist am einfachsten zu verstehen. Die SOAP Verpackung für Anfragen und Antworten ist ziemlich schwer. Es gibt den Umschlag SOAP, 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 von Identifizierung, Autorisierung usw. durchzuführen. Das Parsen von XML ist jedoch teuer, was die Skalierbarkeit Ihres Systems in gewisser Weise beeinträchtigt. Wie viel davon abhängt, hängt von der Verarbeitungsschicht SOAP in Ihrem Stapel ab.

Bei der Serviceerkennung werden Sie wahrscheinlich am meisten Streit haben. REST bietet naturgemäß vorhersagbare 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 erraten können, wie sie das tun sollen, was sie benötigen, sobald sie die URL-Struktur Ihrer Website verstanden haben. Naive sicherheitsbewusste Menschen werden das natürlich 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 Sicherheitsprinzipien:

  • Kommunikation verschlüsseln
  • Stellen Sie sicher, dass Sie Benutzer authentifizieren und autorisieren, bevor Sie sie verarbeiten
  • Gute Codierungsgewohnheiten, um direkte Angriffe zu vermeiden
  • Und das ist nur die kurze Liste.

Denken Sie an Dunkelheit! = Sicherheit.

Leistung

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

Komplexität

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

Aus Sicht des Programmierers kann SOAP gewinnen, wenn das von Ihnen verwendete IDE oder Framework eine gute Unterstützung bietet. Im Wesentlichen liegt es bei REST an Ihnen, die Vorverarbeitungsarbeiten (Authentifizierung/Autorisierung/usw.) durchzuführen, während bei SOAP ein Großteil davon mit einer steckbaren Verarbeitungskette erreicht werden kann.

Meine Präferenz

Ich bin sehr zufrieden mit HTTP-Anfragen und weiß, wie das Web funktioniert. Infolgedessen ist der Ansatz REST für mich vorzuziehen. Ich weiß jedoch, dass einige meiner Kunden sich damit nicht wohl fühlen. Sie haben einen Branchenartikel gelesen, in dem die Sicherheit von REST gegenüber 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 sie sein muss. Offensichtlich verlangt (oder wünscht) eine soziale Webanwendung nicht so viel Sicherheit wie eine Bank oder ein 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, sie zu suchen und einzurichten.

13
Berin Loritsch
  1. Sicherheit: Verwenden Sie HTTPS. Dies gilt für beide.
  2. Leistung: . REST ist weniger CPU-teuer (weniger Parsen, Marshalling, Entpacken). Auch das Zwischenspeichern mit REST ist ein Kinderspiel.
  3. Komplexität: REST erfordert viel weniger Setup, es ist schließlich nur GET/POST. SOAP erfordert viel mehr Administration für die Wartung (wsdl usw.), ist jedoch etwas einfacher, wenn Ihre IDE dies unterstützt).

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

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

12
Martin Wickman

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

Leider besteht ein häufiger Missbrauch von REST darin, Ihre inneren Datenstrukturen freizulegen (im schlimmsten Fall handelt es sich um eine CRUD Ihrer Datenbank, ugh). Das macht es sehr Es ist schwierig, dies sicher zu tun. Die "richtige" Verwendung besteht darin, Objekte auf hoher Ebene verfügbar zu machen, die für den Teil des Systems relevant sind, den Sie handhaben, und Fehlerstatuscodes bei Inkonsistenzen 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 einmaliger oder mehrmaliger Anwendung genau das gleiche Ergebnis erzielen (Sie sind frei von Rückgabe eines 404, falls bereits gelöscht, oder 'keine Änderung', wenn der Client dasselbe setzt) ​​Dies führt zu robusten Systemen und einer geringeren gegenseitigen Abhängigkeit der exakten Interpretationen der Semantik.

8
Javier

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

Menschen, die eine Internet-Webanwendung wie Sie erstellen, sind mit ziemlicher Sicherheit besser dran, eine RESTful-Architektur zu verwenden. Fast jede Plattform kann es nutzen und dies einfach und ohne sich Gedanken darüber zu machen, welche Version welcher Spezifikation Sie verwenden und eine Vielzahl von werkzeugspezifischen Typkonvertierungs-Macken usw.

3
Jeremy

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

0
Wyatt Barnett