© Norrapat_Thepnarin/Shutterstock.com, © S&S Media
Windows Developer
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 entspreche...

Windows Developer
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.

Rainer Stropek


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 entspreche...

Angebote für Teams

Für Firmen haben wir individuelle Teamlizenzen. Wir erstellen Ihnen gerne ein passendes Angebot.

Das Library-Modell:
IP-Zugang

Das Company-Modell:
Domain-Zugang