Rainer Stropek time cockpit

„Die ASP.NET-Core-Implementierung ist gut gelungen. Mit EF Core im Hintergrund ist der Entwicklungsaufwand für einen OData Service in ASP.NET Core minimal.“

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 Sisyphus-Arbeit. Der OData-Standard 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.

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.

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.

 

Den vollständigen Artikel lesen Sie in der Ausgabe:

Windows Developer 11.18 - "Kernkompetenz .NET Core"

Alle Infos zum Heft
579860775OData ist in .NET Core angekommen
X
- Gib Deinen Standort ein -
- or -