REST-API

Ein RESTful (Representational State Transfer) Webservice ist ein Webdienst, der mit einer Architektur speziell für dezentrale Systeme gestaltet ist. Alle RESTful Webservices zusammen auf einem Server werden als REST-API (Application Programming Interface) bezeichnet.

REST-APIs werden häufig direkt mit dem HTTP-Protokoll in Verbindung gebracht, sind jedoch weder ein Standard noch ein Protokoll. Es gibt – definitionsgemäß – verschiedene Protokolle, die für die Kommunikation mit REST-APIs angewendet werden können, HTTP ist lediglich das gängigste.

Eine REST-API muss sechs verschiedenen Architekturdefinitionen entsprechen, die in der Spezifikation genannt sind:

• Client-Server-Modell: Daten und Benutzerschnittstelle müssen definitionsgemäß getrennt sein.
• Zustandslosigkeit: Client und Server müssen zustandslos kommunizieren. Jede Client-Anfrage muss alle Informationen enthalten, die der Server für die Verarbeitung der Anfrage benötigt.
• Caching: Informationen können als im Cache speicherbar oder nicht im Cache speicherbar eingestuft werden. Ein Client kann Serverantworten für künftige Anfragen im Cache speichern, diese Informationen könnten aber veraltet sein.
• Einheitliche Schnittstelle: REST-Schnittstellen müssen aufgrund ihrer einheitlichen Schnittstelle von verschiedenen Endpunkten identisch nutzbar sein.
• Mehrschichtige Systeme: Eine REST-API muss ein mehrschichtiges, hierarchisch aufgebautes System sein.
• Code-On-Demand (optional): Die Funktionen der Clients müssen mit nachladbaren und ausführbaren Programmteilen erweiterbar sein.

Anforderung von Ressourcen von einer REST-API

Wie bereits erwähnt, ist HTTP(S) nur eine der Möglichkeiten, um eine REST-API zu implementieren, doch es ist die einzige, die für diese Dokumentation von Bedeutung ist. Der folgende Abschnitt enthält eine kurze Beschreibung, wie Ressourcen von einer REST-API angefordert werden, die mit HTTP(S) implementiert ist.

Eine Ressource auf einer HTTPS-REST-API wird mit ihrer URL identifiziert. Es gibt zwei verschiedene Möglichkeiten, wie eine URL von einem Webservice angeboten werden kann. Zum einen kann eine URL nur aus Pfadparametern bestehen und zum anderen könnte sie Abfrageparameter enthalten. Der Unterschied zwischen diesen beiden Möglichkeiten wird am folgenden Beispiel erläutert.

Eine URL ist aus drei Teilen aufgebaut:

1. Domainname
2. Pfadparameter
3. Abfrageparameter

Wenn das Wetter für die Stadt Verl von einem fiktiven Beckhoff-Wetterdienst angefordert werden soll, könnte die URL ohne Abfrageparameter wie folgt aussehen:

https://www.beckhoff-weather.com/forecast/city/verl

Mit Abfrageparametern könnte die URL folgendermaßen aussehen:

https://www.beckhoff-weather.com/forecast?city=verl

Der erste Teil https://www.beckhoff-weather.com ist der Domainname des Webservers, der mit Hilfe eines DNS-Servers in eine IP-Adresse umgewandelt wird. Die Pfadparameter /forecast/city/verl geben an, auf welcher Ressource des Servers die Anfrage verarbeitet werden soll. Eine weitere Möglichkeit ist die Verwendung eines Abfrageparameters wie forecast?city=verl, um eine spezifische Ressource auf einem Pfad anzufordern.