Mobile Apps mit den SAP Cloud Platform Mobile Services

2.1 REST und OData

Um OData (englisch für »Open Data Protocol«) begreifen zu können, ist es notwendig, das grundlegende Konzept REST und die Prinzipien einer RESTful API zu verstehen. Diese werden im Folgenden erläutert.

2.1.1 REST

REpresentational State Transfer bzw. REST ist der Architekturstil des Webs. Er wurde in der Dissertation¹ von Roy Thomas Fielding, einem der Hauptautoren der HTTP-Spezifikation, über die folgenden sechs Kriterien charakterisiert:

• Client-Server: Es liegt eine Client-Server-Architektur zugrunde. In dieser bieten Server Dienste (Services) an. Clients (z.B. ein Webbrowser oder eine App) können Anfragen (Requests) an diese Dienste stellen, welche vom Server beantwortet werden (Response).
• Zustandslosigkeit (Stateless): Jede Anfrage vom Client an einen Server enthält alle Informationen, die benötigt werden, damit der Server die Anfrage beantworten kann.
• Puffer (Cache): Antworten sind implizit oder explizit als pufferbar (cacheable) markiert, sodass solche Anfragen auch aus einem Puffer heraus bedient werden können.
• Einheitliche Schnittstelle (Uniform Interface): Ressourcen sind identifizierbar, sie können durch ihre Repräsentation manipuliert werden, und Nachrichten sind selbstbeschreibend. Zudem kommt »Hypermedia as the engine of application state« (HATEOAS) zum Einsatz: Der Client kann von Ressource zu Ressource navigieren, wie ein Internetnutzer auf einer Webseite von Link zu Link springen kann.
• Mehrschichtigkeit (Layered System): Es können mehrere »Schichten« von Systemen vorhanden sein, aber für den Client ist stets transparent, wie viele Schichten involviert sind. So kann ein Server als Client den Service eines anderen Servers benutzen, um eine Anfrage zu beantworten.
• Code on Demand (optional): Der Server kann in seinen Antworten an den Client zusätzlichen ausführbaren Code übermitteln. Dies ist z.B. im Web der Fall, wenn der Server JavaScript-Code bereitstellt, der dann im Webbrowser auf dem Client ausgeführt wird.

Eine RESTful API ist eine Schnittstelle zwischen zwei Systemen, die auf HTTP basiert und diesen Kriterien folgt. Letztere lassen jedoch zu viele Freiheiten beim Entwurf und der Implementierung einer RESTful API, um von einem »Standard« sprechen zu können. OData formuliert daher zusätzliche Anforderungen, um einen standardisierteren API-Entwurf zu gestatten.

2.1.2 OData

OData ist ein offener OASIS-Standard, der Best Practices für die Erstellung und Verwendung von abfragbaren und interoperablen RESTful APIs definiert. OData ermöglicht eine Datenmodelldefinition in Form eines Entitätsdatenmodells (Entity Data Model [EDM]) sowie die Abfrage und Veränderung von Daten auf Basis dieses Datenmodells.

Jeder OData-Service ist unter einem bestimmten Endpunkt zu erreichen. Es gibt eine Reihe von Test-OData-Services, die unter https://services.odata.org bereitgestellt und ausprobiert werden können. Der Endpunkt eines der Test-OData-Services ist z.B.:

https://services.odata.org/V2/OData/OData.svc/

In einem Entitätsdatenmodell gibt es Objekte, sog. Entitäten, welche einzeln die Instanz eines bestimmten Entitätstyps bilden, der wiederum durch eine Menge von benannten und typisierten Eigenschaften charakterisiert ist. Eine Teilmenge der Eigenschaften bildet den Schlüssel des Entitätstyps und dient der Identifikation seiner Entitäten. Der Typ einer Eigenschaft ist entweder ein vordefinierter primitiver Daten- oder ein sog. komplexer Typ, der aus einigen primitiven Datentypen besteht und selbst keine Schlüsseleigenschaften besitzt. Mehrere Entitäten werden in Entitätsmengen zusammengefasst.

Beziehungen zwischen Entitätstypen werden durch Assoziationen modelliert. Spezifische Navigationseigenschaften eines Entitätstyps ermöglichen die Navigation von einer Entität zur anderen oder zu mehreren Entitäten über eine seiner Assoziationen.

Das Datenmodell des Test-OData-Services ist als XML-Metadatendatei unter der folgenden Adresse beschrieben:

https://services.odata.org/V2/OData/OData.svc/$metadata

Dieses Dokument definiert die drei Entitätstypen Product, Category und Supplier. Ein Supplier ist gekennzeichnet durch die Eigenschaften

• ID vom vordefinierten Typ Edm.Int32,
• Name vom vordefinierten Typ Edm.String,
• Concurrency vom vordefinierten Typ Edm.Int32 und
• Address vom komplexen Typ Address.

Der komplexe Typ Address umfasst die Eigenschaften Street, City, State, Zipcode und Country vom vordefinierten Typ Edm.String. Der Schlüssel des Entitätstyps Supplier ist die Eigenschaft ID.

In dem Dokument wird darüber hinaus u.a. eine Assoziation zwischen den Entitätstypen Product und Supplier mit dem Namen Product_Supplier_Supplier_Products definiert. Hier wird ein Produkt maximal einem Lieferanten zugeordnet. Über die Navigationseigenschaft Products kann man vom Supplier zu den zugeordneten Produkten navigieren. Das Modell definiert weiter, dass mehrere Entitäten des Entitätstyps Product in der Entitätsmenge Products zusammengefasst werden.

Sie können die vorhandenen Daten über einfache HTTP-Anfragen im Browser einsehen. So ermittelt beispielsweise ein Aufruf der folgenden URL alle Lieferanten:

https://services.odata.org/V2/OData/OData.svc/Suppliers

Mit der nächsten URL können alle Produkte bestimmt werden:

https://services.odata.org/V2/OData/OData.svc/Products

Mit OData ist es auch möglich, Filteranfragen zu formulieren. Der Zusatz ?$filter=Price le 5 liefert bei Anfrage alle Produkte mit einem Preis kleiner oder gleich dem Wert »5« zurück (Leerzeichen in der URL werden mit %20 maskiert):

https://services.odata.org/V2/OData/OData.svc/Products?$filter=Price%20LE%205

Ein einzelner Lieferant ist unter Angabe seines Schlüssels zu finden:

https://services.odata.org/V2/OData/OData.svc/Suppliers(0)

Durch Angabe der Navigationseigenschaft Products gelangen Sie zu allen Produkten des Lieferanten mit der ID »0«:

https://services.odata.org/V2/OData/OData.svc/Suppliers(0)/Products

Durch die Eingabe einer URL in den Browser wird eine HTTP-Anfrage mit der HTTP-Methode GET ausgeführt. Während auf diese Weise Daten abgefragt werden können, sind Veränderungen der Daten nur mit speziellen REST-Clients oder programmatisch möglich. Das Prinzip ist jedoch sehr ähnlich: Eine Anfrage mit der HTTP-Methode DELETE an die folgende URL würde den Lieferanten mit der ID »0« löschen:

https://services.odata.org/V2/OData/OData.svc/Suppliers(0)

Eine Anfrage mit der HTTP-Methode POST zusammen mit einer Beschreibung eines neuen Lieferanten an die folgende URL würde einen neuen Lieferanten erzeugen:

https://services.odata.org/V2/OData/OData.svc/Suppliers

OData erleichtert die Entwicklung von wiederverwendbaren REST-Services und ist durch seinen entitätsorientierten Ansatz gut für die Verarbeitung von Business-Objekten geeignet. Zusätzlich ermöglicht diese Art des REST-API-Designs ein weitgehend standardisiertes Offline-Synchronisationsverfahren auf Basis der Modellmetadaten, das sonst bei einer vollkommen »freien« Implementierung schwierig zu vereinheitlichen wäre. Die SAP bietet in ihren Produkten viele fertige OData-Services an, die leicht in neue Anwendungen integriert werden können.

Im Folgenden werden einige typische Architekturvarianten beschrieben, wie OData-Services bereitgestellt werden.