Anwendung kümmert, sondern der Client diese Aufgabe übernimmt. Für eine REST-Anfrage bedeutet dies, dass sämtliche Parameter oder Daten in einer Anfrage mitgesendet werden müssen, damit sie auch verstanden wird. Man kann sich nicht darauf verlassen, dass Daten am Server vorhanden sind, die einen Zustand repräsentieren.
Verwendung von Hypermedia als Motor für den Anwendungszustand (HATEOAS)
HATEOAS lässt sich mit „Hypermedia als Motor für den Anwendungszustand“ übersetzen. Diese Eigenschaft ist recht unkompliziert. Es bedeutet lediglich, dass Standard-Hypermedia-Elemente für REST verwendet werden sollen, beispielsweise Links. Hat eine Anfrage viele Kundendaten, kann man einen einzelnen Kunden wiederum durch eine REST-Anfrage darstellen. Somit wird die Rückgabe von Daten wesentlich schlanker.
Folgendes demonstriert die Rückgabe von Kunden:
1
Anonymous
Vienna
2
Super Anonymous
Linz
...
Unter Rücksichtname auf HATEOAS kann die Anfrage folgendermaßen aussehen:
https://codeforce.at/services/
customers/?id=1
https://codeforce.at/services/
customers/?id=2 Das macht eine Anfrage wesentlich einfacher und schlanker.
Damit die Eigenschaften von REST deutlicher werden, wollen wir ein Szenario für eine Geschäftslogik entwerfen. Stellen wir uns einen Buchverlag vor. Dieser Buchverlag soll Autoren und Bücher haben, die Bücher haben einige Attribute, etwa ISBN-Nummer, Autor, Preis, Titel und vorhandene Lagermenge. Der Autor hat die Attribute der geschriebenen Bücher, Vor- und Nachnamen sowie Geburtsdatum. Das entsprechende Diagramm ist in Abbildung 4.1 dargestellt.
Abbildung 4.1 Autoren und Bücher als Klassendiagramm
Nun werden für dieses Szenario einige grundlegende Operationen benötigt, am augenscheinlichsten sind die Auflistung der Autoren und der Bücher. Das funktioniert über einen einfachen HTTP GET. Zu beachten gilt jedoch, dass es bei großen Datenmengen zu etwaigen Verzögerungen oder im schlimmsten Fall zu einem Timeout kommt. Daher sollten nur Teile zurückgeliefert werden. Wie das gehandhabt wird, obliegt der eigenen Anwendung und dem Web Service.
Will man alle Autoren abfragen, sieht das folgendermaßen aus:
GET https://codeforce.at/rest/api/authors
Nun bekommt man eine Response als Rückgabe. Da REST auf kein bestimmtes Format ausgelegt ist, kann das beliebig aussehen. Es wäre beispielsweise eine CSV-Liste denkbar:
Response Status:
HTTP/1.1 200 OK
Response Headers:
Content-Type: application/text
Date: Fri, 15Aug 201023:00:00 GMT
Server: CodeForce AT Services Server
Response Body:
0,Mario,Meir-Huber,Tue 3 Jan 1984 06:04:00 GMT
1,Daniel,Meir-Huber,Tue 3 Sep 1986 12:00:00 GMT
In den meisten Fällen wird für diese Art von Services jedoch XML verwendet. Liefert der eben adressierte Service XML-Daten zurück, könnte es folgendermaßen aussehen:
Response Status:
HTTP/1.1 200 OK
Response Headers:
Content-Type: application/text
Date: Fri, 15 Aug 2010 23:00:00 GMT
Server: CodeForce AT Services Server
Response Body:
0
Mario
Meir-Huber
3 Jan 1984 06:04:00 GMTBirthday>
0
Daniel
Meir-Huber
3 Sep 1986 12:00:00 GMTBirthday>
Hier sieht man bereits, dass man mit REST eine sehr hohe Flexibilität hat. Will man einen einzelnen Datensatz haben, kann das mit einem Identifier (der in unserem Fall die Guid_ID ist) regeln. Der Identifier wird entweder per URL oder mit einem Parameter gesetzt. Per URL sieht es folgendermaßen aus:
GET https://codeforce.at/rest/api/authors/1
Und per Parameter:
GET https://codeforce.at/rest/api/authors/?id=1
Wichtig ist auch die korrekte Verwendung von DELETE. Will man ein Buch löschen, geschieht das mit dem DELETE-Befehl. Es ist ein großer Fehler, wenn Ressourcen über Parameter gelöscht werden. Wird ein Buch gelöscht, würde das so aussehen:
DELETE https://codeforce.at/rest/api/books/1
In diesem Fall wird das Buch mit dem Index 1 gelöscht, im Diagramm in Abbildung 2.2 das Buch mit der Book_ID auf 1. Komplexer wird das Beispiel nun, wenn man
Kostenlos Online Lesen 
