© Norrapat_Thepnarin/Shutterstock.com, © S&S Media
OData ist in .NET Core angekommen

Daten fürs API


Wenn es um Microservices geht, entscheiden sich viele Entwicklungsteams für RESTful-Web-APIs. Eine besondere Herausforderung sind solche APIs, wenn es keine klar abgegrenzten Funktionen gibt. Der eine API-Konsument möchte die Kundenliste nach Namen filtern, der nächste will alle Kunden in einem bestimmten Land und der übernächste braucht Funktionen zum Blättern (Skip/Take). Für jeden Anwendungsfall eine eigene API-Methode? Das wäre eine endlose Sisyphusarbeit. Der OData-Standard [1] bietet hier Abhilfe, auch mit .NET Core.

Für das .NET Framework gibt es seit Jahren sehr gute OData-Unterstützung. In .NET Core hatte man bisher das Nachsehen. Aber seit Juli 2018 ist OData auch in ASP.NET Core 2 angekommen. Grund genug, das etablierte und weit verbreitete Protokoll in diesem Artikel wieder einmal in Erinnerung zu rufen und sich anzusehen, wie die Integration in ASP.NET Core aussieht.

Warum OData?

Manche Anwendungen haben von Natur aus eine begrenzte Liste an unterschiedlichen Funktionen. Jede Funktion hat eine klar definierte Aufgabe mit festgelegten Parametern und Rückgabewerten. Will man ein solches Web-API implementieren, hat man mit ASP.NET Core eine wunderbare Plattform.

Es gibt aber auch datengetriebene Anwendungen, bei denen das Definieren des Web-API nicht so einfach ist. Man könnte für jede Entität (z. B. Kunden, Aufträge, Bestellungen etc.) die klassischen CRUD-Operationen (Create, Read, Update, Delete) als API-Endpoints anbieten. Beim Read wird es aber schwierig. Ein einziges API, das alle Datensätze zurückgibt, ist selten ausreichend. Die API-Konsumenten sollen je nach Anwendungsfall filtern, sortieren, blättern, joinen etc. können. Das OData-Protokoll löst dieses Problem. Es ist eine detaillierte Anleitung, wie man ein datengetriebenes RESTful-Web-API aufbaut. Ein wichtiger Teil von OData ist dabei die Abfragesprache. So wie SQL SELECT eine flexible, standardisierte Abfragesprache für relationale Datenbanken ist, enthält OData eine Abfragesprache für den URL.

Tabelle 1 stellt beispielhaft einige SELECT-Statements den entsprechenden OData-URLs gegenüber. Die Beispiele sind sehr einfach gehalten, man darf sich dadurch aber nicht täuschen lassen. Die Abfragesprache von OData ist mächtig. An die Funktionalität und Flexibilität von SQL SELECT kommt sie zwar nicht heran, für die meisten Web-API-bezogenen Anwendungsfälle ist sie aber mehr als ausreichend. Wer Details über den Funktionsumfang wissen möchte, dem empfehle ich einen Blick in den entsprechenden Teil der OData-Spezifikation [2].

SQL SELECT

OData URL

SELECT * FROM Products

WHERE Name = 'Milk'

http://host/odata/Products?$filter=Name eq 'Milk'

SELECT ID, Name FROM Products

http://host/service/Products?$select=ID,Name

SELECT TOP(10) * FROM Products

http://host/odata/Products?$top=10

SELECT * FROM Products

LEFT JOIN Category ON

http://host/service/Products?$expand=Category

Tabelle 1: OData vs. SQL SELECT

OData ist aber nicht auf die Abfrage von Daten beschränkt. Der Standard deckt fast alle Aspekte ab, die man für ein professionelles RESTful-Web-API braucht. Dazu gehören insbesondere:

  • Festlegungen für HTTP Headers und Status Codes [3]

  • Regeln für den Aufbau der JSON Payload [4]

  • Protokoll für das Schreiben von Daten (Create, Update, Upsert, Delete, Batch Requests etc.) [3]

  • Standard für das Abfragen von Metadaten (z. B. Entitäten, Felder, Beziehungen zwischen Entitäten etc.) [5]

Warum überhaupt ein Standard?

Es stellt sich die Frage, warum sich ein Entwicklungsteam dem OData-Standard unterwerfen und nicht stattdessen eigene Wege gehen soll, die perfekt zur jeweiligen Aufgabenstellung passen. Schließlich haben Standards nicht nur Vorteile. Oft fehlen Aspekte, die für das eigene Projekt wichtig sind. Andererseits sind Dinge vom Standard gefordert, die für den konkreten Anwendungsfall nicht notwendig wären.

Der erste, wichtige Vorteil, den ich in OData sehe, ist eben genau die Tatsache, dass es sich um einen Standard handelt. Es gibt generische Clients, die OData verstehen. Hat man ein OData-konformes Web-API, kann man diese Clients nutzen. Ein Beispiel für einen solchen Client ist Power BI (Abb. 1), die Business-Intelligence-Lösung von Microsoft. Für Entwickler vielleicht spannender ist beispielsweise die Open-Source-UI-Bibliothek Kendo UI von Progress. Einige Controls aus dieser Bibliothek kommen mit eingebauter Unterstützung für OData Web APIs (z. B. Autocomplete Combobox [6]).

Ein weiterer Vorteil ist die weite Verbreitung von OData. Speziell im Microsoft- und SAP-Umfeld sind OData-konforme Web-APIs häufig zu finden. Viele Teams, die in diesem Bereich arbeiten, haben daher bestehendes Wissen bezüglich OData und können sich schnell in neue Web-APIs, die diesem Standard entsprechen, einarbeiten.

stropek_odata_1.tif_fmt1.jpgAbb. 1: Zugriff auf OData in Power BI

Der dritte Vorteil, den ich an dieser Stelle erwähnen möchte, hat nur indirekt mit dem Standard und mehr mit der Umsetzung in ASP.NET zu tun. OData bietet sehr viele Funktionen. Das Protokoll von Grund auf selbst zu programmieren, ist daher langwierig. Microsoft bietet aber eine Erweiterung von ASP.NET, mit der man mit sehr geringem Entwicklungsaufwand zu einem OData-Web-API kommt. Insofern bedeutet die Kombination OData plus ASP.NET in manchen Projekten eine Reduktion des Entwicklungsaufwands bei gleichzeitig umfangreicher Funktionalität.

OData in ASP.NET Core

Genug der Theorie, werfen wir einen Blick auf die Praxis mit OData und ASP.NET Core. Eine vollständige Einführung in ASP.NET OData würde den Rahmen eines Artikels sprengen. Daher konzen...

Neugierig geworden? Wir haben diese Angebote für dich:

Angebote für Gewinner-Teams

Wir bieten Lizenz-Lösungen für Teams jeder Größe: Finden Sie heraus, welche Lösung am besten zu Ihnen passt.

Das Library-Modell:
IP-Zugang

Das Company-Modell:
Domain-Zugang