Hier wird erläutert, wie Sie mit dem WMS eine REST-API (oder eine andere HTTP-API) ansprechen und nutzen können. Es wird zunächst kurz auf die Grundlagen von REST und Http eingegangen. Anhand von Beispielen wird gezeigt, wie Sie mit dem WMS externe Schnittstellen ansprechen.

Was ist eine API?

API steht für “Application Programming Interface” und beschreibt eine Schnittstelle einer Anwendung oder eines Dienstes. Über die Schnittstelle können Daten abgerufen, geändert und auch gelöscht werden. Die API wird von dem jeweiligen Hersteller definiert und unterscheidet sich von Anwendung zu Anwendung. Deshalb sollte die API detailliert beschrieben sein, um diese vernünftig nutzen zu können. Es gibt verschiedene Arten von APIs, jedoch wollen wir uns hier auf diejenigen beschränken, welche über Http angesprochen werden können (z.B. REST-API).

HTTP-Request

Ein HTTP-Request (zu deutsch “Http-Anfrage”) wird von einem Client (in unserem Falle das WMS) an einen benannten Host (die Anwendung auf einem Server, welche die API bereitstellt) gesendet.

Um einen HTTP-Request abzusenden wird als Adresse eine URL (Uniform Resource Locator) verwendet, welche alle Informationen enthalten muss, die die API erwartet. Wie die Bezeichnung “Uniform Resource Locator” bereits ausdrückt, wird mit der URL eine Resource eine “Quelle” adressiert, von der Daten abgerufen bzw. an die Daten gesendet werden können.

Um mit dem Host zu kommunizieren, müssen dem HTTP-Request noch weitere Informationen mitgegeben werden. Diese Informationen sollten in der API-Beschreibung des Herstellers dokumentiert sein.

HTTP-Endpunkt (URL)

Eine URL besteht aus folgenden Teilen (erklärt an der API von Microsoft Graph):

Schema: Gibt das verwendete Protokoll an, mit dem der Request gesendet wird. Hier: http oder https

Host: Der Host-Name identifiziert den Host, welcher die API bereitstellt. Statt dem Host-Namen kann auch dessen IP-Adresse angegeben werden.

Port: Der Port muss angegeben werden, wenn er nicht dem Standard entspricht. (Standard Http-Port: 80, HTTPS: 443)

Pfad: Der Pfad gibt die Resource an, welche adressiert werden soll, im Beispiel /v1.0/me/joinedTeams.
Oftmals gibt es einen Basis-Pfad, welcher bei unterschiedlichen Requests immer gleich bleibt. Im Beispiel wäre dies die Versionsnummer der API /v1.0.
Der Pfad kann auch zu einer Datei führen (einer Html-Datei zur Anzeige im Browser oder eine PDF-Datei zum Herunterladen von Binärdaten)

Query: Beim Absetzen eines Requests kommt es häufig vor, dass zusätzliche Parameter (z.B. Filter oder IDs) mitgegeben werden müssen. Die Query besteht aus ein oder mehreren Namen/Werte-Paaren, welche mit einem “&” separiert werden, und wird am Ende des Pfades mit einem “?” angehängt (z.B. ?user=Mustermann&zipcode=83022).
Fragment: Mit dem Fragmentbezeichner (eingeleitet mit einem #) kann eine Untereinheit einer Ressource adressiert werden kann.

HTTP Methode

Mit der Methode wird angegeben, was mit den Daten gemacht werden soll. Am gebräuchlichsten ist die Methode GET, mit der Daten von einer API abgerufen werden können. Darüber hinaus gibt es noch die Methoden PATCH, POST, PUT, DELETE und weitere, mit denen Daten geändert bzw. gelöscht werden können.

HTTP Header

Die Header werden als Liste von Namen/Werte-Paaren mitgegeben. Im Header werden Informationen über den Sender und die Kommunikation mitgegeben, z.B. auch die Formatierung der im Content übergebenen Daten. Welche Header benötigt werden, sollte in der API beschrieben sein.

Content

Im Content (auch als Body bezeichnet) werden dem HTTP-Request zusätzliche Daten mitgegeben. Dies ist üblicherweise bei Hinzufügen oder Ändern von Daten der Fall (also bei den Methoden PATCH, POST, PUT). Der Content kann Textform (z.B. im Json- oder XML-Format) oder als Name/Wert-Paare (form-url-encoded) übergeben werden. Daten werden dann bevorzugt im Content übermittelt, wenn sie sehr umfangreich sind oder nicht in der URL ersichtlich sein sollen.

HTTP-Response

Wurde ein HTTP-Request abgesetzt, gibt der Host eine Antwort auf den Request zurück, die sog. HTTP-Response. Mit der HTTP-Response werden folgende Informationen zurückgegeben:

Ein Status-Code, ein 3-stelliger numerischer Wert, mit dem die erfolgreiche Ausführung des HTTP-Request bestätigt (Status-Code 200) oder eine nicht ordnungsgemäße Anfrage angezeigt wird. Der Status-Code wird in folgende 5 Gruppen unterteilt:

• 1xx - Informell
  Die Anfrage wurde empfangen und die serverseitige Verarbeitung wird fortgesetzt

• 2xx - Erfolgreich
  Die Anfrage wurde erfolgreich empfangen und angenommen

• 3xx - Nachsendung
  Weitere Aktionen sind erforderlich, um den Request abzuschließen

• 4xx - Fehler beim Client
  Der HTTP-Request enthält eine ungültige Syntax und kann nicht ausgeführt werden (z.B. fehlende oder ungültige Credentials)

• 5xx - Fehler beim Host
  Bei der Verarbeitung auf dem Server sind Fehler aufgetreten

Details zu den einzelnen Codes können Sie hier nachlesen: https://de.wikipedia.org/wiki/HTTP-Statuscode.

Der Grund des Status-Codes, welcher eine textuelle Beschreibung im Falle eines Fehlers beinhaltet.

Eine Liste mit Headern, welche zusätzliche Informationen zum Host und der Kommunikation liefern, darunter auch die Formatierung eines zurückgegebenen Contents.

Im Content (auch als Body bezeichnet) werden die angeforderten Daten zurückgegeben.

REST

REST steht für REpresentational State Transfer und stellt eine Architektur für die Kommunikation von verteilten Anwendungen dar. Mit REST werden Prinzipien definiert, welche von einer API umgesetzt sein müssen, wenn diese als REST API bezeichnet wird. Werden alle diese Prinzipien von einer Service-Schnittstelle implementiert, wird diese auch als RESTful bezeichnet.

Im Sprachgebrauch werden häufig Http-APIs als REST-API bezeichnet, auch wenn sie die Kriterien nicht erfüllen.

In der Regel basiert eine REST API auf dem HTTP-Protokoll und kann dann uneingeschränkt mit HTTP-Requests angesprochen werden.