Philipp Friberg itelligence Schweiz AG

OData eignet sich nicht nur für Webapplikationen; wir haben auch schon OData für die Maschinen-Maschinen-Kommunikation eingesetzt.

RESTful APIs sind in aller Munde, doch leider sind damit Fragen der Objektadressierung, Suche, Filterung oder die Abbildung eines Objekts noch nicht geklärt. All das und andere Best Practices für das Bilden von REST-APIs hat uns der OData-Standard abgenommen. Dank der Metadaten, die ein Service mit seinem Modell beschreibt, ist es auch für Entwickler einfacher, den Service zu verstehen und damit erfolgreich zu arbeiten.

Für die Kommunikation zwischen Maschinen gibt es verschiedene Protokolle, wie z. B. Web Services, RPC und andere. Gerade Web Services mit dem SOAP-Protokoll und den WSDL-Dateien gelten eher als schwerfällig und passen nicht in die moderne Welt von Webapplikationen. Da wird eher das REST-Protokoll verwendet, oft auch „leichtgewichtige“ Web Services genannt – was aber aus meiner Sicht nicht ganz zu vergleichen ist: SOAP ist eine RPC-Middleware, mit der komplexe Protokolle gebaut werden können und generell an einen Endpunkt adressiert wird. Bei REST-Protokollen hingegen erfolgt eine direkte Adressierung der Objekte. Es setzt auf dem HTTP-Protokoll auf und verwendet folglich dessen meistverwendete Methoden GET, POST, DELETE und PATCH/PUT. Die Grundideen vom REST-Protokoll sind:

  • Unabhängigkeit von der Plattform: Es ist also egal, ob z. B. Linux- oder Windows-Systeme miteinander kommunizieren.
  • Unabhängigkeit von der Programmiersprache: Deshalb werden in der Regel JSON- oder XML-Nachrichten verwendet.
  • Basierend auf dem HTTP-Protokoll: Es ist somit cachebar und es sind standardisierte Regelwerke für Firewalls möglich.
  • Zustandslosigkeit: Jede Nachricht enthält alle notwendigen Informationen für eine erfolgreiche Verarbeitung.

Um sich einen REST-Aufruf vorstellen zu können, kann man z. B. mit folgendem HTTP Request alle Orders (Bestellungen) anzeigen: GET /SalesOrderSet HTTP/1.1. Als Antwort könnte etwas wie in Listing 1 gezeigt zurückkommen.

{
  "d" : {
    "results" : [
      {
        "CreationDateTime" : "\/Date(1481065200000+0000)\/",
        "Customer" : "100000005",
        "GrossAmountInTransacCurrency" : "5631.080",
        "LastChangedDateTime" : "\/Date(1481065200000+0000)\/",
        "NetAmountInTransactionCurrency" : "4732.000",
        "SalesOrder" : "500004522",
        "TaxAmountInTransactionCurrency" : "899.080",
        "TransactionCurrency" : "EUR",
        "SalesOrder_Text" : "Text zu Salesorder 0500004522"
        ...
      }
    ]
  }
}

Soweit ist das ja ganz gut, eine Bestellung dürfte aber einen Kunden haben, eine Lieferadresse, Positionen usw. Also müsste man als Nächstes die Details zu solch einer Bestellung abfragen. Weiter wäre es spannend, die Relationen zu den anderen Objekten adressieren zu können, also z. B. „Gib mir die Details zum Kunden der Bestellung“. Klar, diese Datenmodellierung ist unsere Aufgabe als Entwickler. Auch ist es unsere Aufgabe, die URI-Definition zur Verfügung zu stellen und den Content so zurückzugegeben, dass sich eine Bibliothek durch das Datenmodell hangeln kann. Dazu gibt es verschiedene Hilfsmittel und Methoden; eine davon ist OData.

Den vollständigen Artikel lesen Sie in der Ausgabe:

Entwickler Magazin 3.17 - "The best Way to REST"

Alle Infos zum Heft
579793610RESTful APIs mit OData
X
- Gib Deinen Standort ein -
- or -