Download (5Mb) - oops/ - Oldenburger Online-Publikations-Server

2.7 REST und RESTful Web Services 25
änderten Schnittstelle. Eine weitere Einschränkung ist die Verwendung von Zwischenspeicherung
(engl. Caching): behandelte Anfragen können mit der Information bereichert werden, ob sie für die
Zwischenspeicherung geeignet sind oder nicht.
Zu der Abstraktion oder “Automatisierung” des Kommunikationsvorgangs zählt auch die Benutzung
von Hypermedia (wie beispielsweise Hyperlinks in einem Hypertext). Deswegen soll eine Antwort
Referenzen zu weiter verknüpften Ressourcen oder noch verwendbaren Operationen zu dem aktuellen
Ressourcen-Typ enthalten. Dadurch wird der Vorgang “automatisch” gesteuert, indem der Client
nur entlang der vorgeschlagenen, weiteren Verknüpfungen navigieren sollte, um sich der Antwort
zur formulierten Anfrage zu nähern. Für den Umgang mit Hypermedia werden in der Praxis sogenannte
Hypertext Application Languages wie HAL 7 oder Hypermedia Types wie Collection+JSON 8
entwickelt. Diese sind als Vorschläge an den W3C eingereicht worden.
Nah verknüpft mit REST sind RESTful Web Services (auch als ein RESTFul Web API bekannt),
die mittels der REST Prinzipien HTTP-basierte Web Services definieren. Das erste Merkmal eines
RESTful Web Service ist die Basis-URI, die definiert, an welcher URI die HTTP Anfragen formuliert
werden müssen. Um auf eine bestimmte Ressource zuzugreifen, muss normalerweise die Basis-URI
mit dem Namen der gewünschten Ressource ergänzt werden.
Zusätzlich enthalten die Web Services, wie oben aufgeführt, auch präzise Angaben der unterstützten
Repräsentationen der Ressourcen – z.B. JSON, XML o.Ä. Das genannte Vokabular von HTTP-
Methoden muss auch vorhanden sein: ein Web Service veröffentlicht auch seine unterstützten HTTP
Methoden, z.B. kann die Beschreibung des Web Services deutlich machen, dass beispielsweise das
HTTP Verb PUT nicht unterstützt wird. Ein letzter Aspekt eines RESTful Web Services ist die
Hypermedia-gesteuerte Entdeckung von weiteren möglichen Pfaden bzw. URIs.
Ein Unterschied eines RESTful Web APIs zu beliebigen Web Services wird auch durch die Benutzung
von sogenannten “Clean URIs” eindeutig. Ein Clean URI oder ein “Benutzerfreundlicher
URI” enthält kein Query String (ein durch ein Fragezeichen getrennter Bestandteil), sondern nur das
verwendete Protokoll (z.B. http) und die Domäne (die Autorität, wie z.B. iana.org). Der Unterschied
wird mit der Vorstellung eines Beispieles dargestellt:
Eine Query-String basierte URI wie http://iana.org/service.jsp?cat=int&id=registrar
ist äquivalent zu der bereinigten Variante http://iana.org/service/int/registrar.
Vorteilhaft an Clean URIs ist die Beständigkeit: wenn die Ressource immer noch existiert, wird die
URI für eine lange Zeit noch erreichbar sein. Zugleich lässt sich ein Clean URI leichter und logischer
eingeben und behalten.
Zusammenfassend lassen sich die REST Prinzipien für die Bereitstellung von REST-basierten Web
Services anwenden, die in dieser Arbeit eine wichtige Rolle für die Kommunikation zwischen Frontend
und Backend spielen wird, wie im Abschnitt 5.2.1 erläutert wird. Zugleich lässt sich mithilfe von
REST Web Services auch der Prinzip von Service Discovery umsetzen, wie es in dem kommenden
Paragraph vorgestellt wird.
7
http://stateless.co/hal_specification.html
8
http://www.amundsen.com/media-types/collection/