REST
Last updated
Was this helpful?
Last updated
Was this helpful?
Refcardz: https://dzone.com/refcardz/rest-foundations-restful
http://www.restapitutorial.com/resources.html
http://blog.philipphauer.de/restful-api-design-best-practices/
Der REST-Webservice-Ansatz kam einige Zeit nach dem SOAP-Webservice-Ansatz auf ...
REST ist kein Standard, sondern ein Architekturstil basierend auf Standards wie beispielsweise das HTTP-Protokoll, MIME-Types, URL, ... Insofern gibt es keine festen Vorgaben (wie bei Standards üblich - siehe ), die unbedingt einzuhalten sind, sondern eher Empfehlungen.
Das SOAP-Ecosystem ist über die Jahre sehr stark gewachsen und hat viele Erweiterungen im Bereich Security, Validierung, XML-Tooling hervorgebracht. Einige dieser Tools können bei der Verwendung von XML als Payload von REST wiederverwendet werden. Allerdings werden REST-Services häufig auf mit JSON als Payload-Format verwendet und dann braucht es neue Tools für
Serialisierung/Deserialisierung
Schnittstellen-Spezifikation und Validierung
...
REST verwendet das HTTP-Protokoll mit seinen Methoden GET, POST, PUT, DELETE ... die verwendete Methode hat in REST eine Bedeutung. Der Payload (beim PUT, POST) wird in den HTTP-Body gepackt ... in einem beliebigen Format (XML, JSON, YAML, Freitext, ...).
Dadurch kann REST allerdings auch weitere Vorteile des HTTP-Protokolls besser nutzen als SOAP:
Caching auf URL-Basis mit der Information innerhalb einer HTTP-Response, ob und wie lange das Ergebnis gecached werden darf.
bookmarkable
Interoperabilität ... es ist kein Custom-SOAP-Protokoll erforderlich
Authentication im HTTP-Header (funktioniert aber auch bei SOAP)
SOAP verwendet das HTTP-Protokoll hingegen nur zum Transport. Im HTTP-Body ist das eigentliche XML-basierte SOAP-Protokoll (<soap:envelope>) erweitert um Custom-Namespaces versteckt:
Deshalb spielt für SOAP auch ausschließlich die HTTP-POST-Methode eine Rolle. Das eigentliche semantische Protokoll wird über HTTP getunnelt und kommt so auch durch die meisten Firmen-Firewalls.
Hintergrund: SOAP kam auf als CORBA und Java-RMI für die Kommunikation zwischen Systemen genutzt wurden. CORBA basierte auf dem IIOP-Protokoll, das von Firmen-Firewalls i. a. blockiert wurde. SOAP setzte deshalb auf HTTP, um dieses Problem zu lösen.
SOAP ermöglicht (es gibt auch andere Vorgehensweisen) die Verwendung eines zentralen MessageDispatchers, so daß alle Nachrichten zur gleichen URL geschickt werden. Der MessageDispatcher interpretiert die im HTTP-Body enthaltenen Nachricht und routet sie weiter.
Für Systemadministatoren könnte dies die Administration erschweren. Bei REST könnte der Admin Zugriffe auf bestimmte Ressourcen mit einer einfachen Regel im Proxy-Server unterbinden, weil alle relevanten Informationen über die HTTP-Methode und die URL abgebildet sind. Bei SOAP hingegen muß das nicht standardisierte Nutzdatenprotokoll analysisert werden ... das ist um einiges aufwendiger und erfordert erhöhten Wartungsaufwand.
Ist nicht möglich ... sofern man im Proxy nicht irgendwelche applikationsspezifische Logik nachbauen will (das kann niemand wollen).
In geschlossenen Umgebungen, über die man gemeinsam bestimmen kann, funktioniert SOAP. In offenen Umgebungen ohne zentrale Entscheider hat sich REST bewährt, weil es das einfachere standardisiertere Protokoll ist und somit Interoperabilität besser unterstützt.
https://en.wikipedia.org/wiki/List_of_HTTP_header_fields
https://en.wikipedia.org/wiki/List_of_HTTP_header_fields#Request_fields
Anmeldung am Server
Kennzeichnet in welchem Style die Antwort akzeptiert wird
Hierüber kann der Client entscheiden, in welchem Format die Ressource vom Server geliefert werden soll (XML, Json, ...). Ein Server muß natürlich nicht alle Formate unterstützen ... das hängt von der Schnittstelle ab.
Hiermit kann der Client seine gewünschte Sprache mitteilen ... das ist evtl. in einer Consumer-Schnittstelle relevant (z. B. die Antwort enthält menschenlesbare Informationen oder es wird vom Server eine eMail verschickt).
Der Server Kennzeichnet hiermit in welchem Format die Antwort versendet wird
Bei einem HTTP-POST oder -PUT kann der Client aber auch das Format des Request-Body kennzeichnen.
https://en.wikipedia.org/wiki/Web_cache#Cache_control
Cache-Control: no-cache
https://en.wikipedia.org/wiki/HTTP_ETag
https://tools.ietf.org/html/rfc7232#section-2.3
Kennzeichnet den Client
https://en.wikipedia.org/wiki/List_of_HTTP_header_fields#Response_fields
Bei REST besteht die Idee, daß ein Client sich ohne weiteres Wissen von einer Ressource zur nächsten Ressource hangeln kann, weil eine Ressource wiederum andere Ressourcen referenziert (über einen HTTP-GET-Request).
Bei SOAP wäre das nicht möglich, weil immer ein HTTP-POST mit SOAP-Envelope erforderlich ist. Das lässt sich nicht in einem einfachen Link unterbringen.
In der Java-Welt gibt es u. a. folgende Ansätze, um RESTful Webservices zu implementieren:
Implementierung CXF
JAX-RS-Spezifikation basiert: ist eine Spezifikation des Java-Community-Process (JSR-339)
Implementierung