Frau Aydin will die Auftragsliste nicht mehr nur im Büro sehen. Der Monteur Herr Kowalski soll auf dem Tablet nachschauen können, was heute ansteht, und später soll die Webseite von Brandt Haustechnik Rechnungen anzeigen. Alle drei brauchen dasselbe: die Aufträge, mit denselben Preisen, von einer Stelle. Diese Stelle ist eine Web-API. Sie ist die Fassade, von der Lektion M1.4 sprach: kein Proxy vor dem alten Programm, sondern eine gemeinsame Schnittstelle, die das Windows-Programm, die Blazor-Seiten und später die Tablets benutzen.
Alles, was die API braucht, haben Sie schon. Die Preisregeln liegen in der Bibliothek aus Lektion M3.1, der Zugriff auf die Datenbank in der Datenschicht aus Lektion M3.2, und die Schutzschicht aus Lektion M3.3 sorgt dafür, dass der neue Code das alte Programm nicht stört. Die API fügt nur eine Sache hinzu: ein HTTP-Gesicht. Wie Minimal APIs, Routen und Parameterbindung funktionieren, steht in K2, Modul 2.3 (ASP.NET Core), und der Entwurf von Schnittstellen in K2, Modul 2.12 (APIs entwerfen). Diese Lektion zeigt, was beim Auftragsbuch besonders ist.
Was wohin gehört
Die API ist dünn. Sie rechnet nichts selbst und fragt die Datenbank nicht mit eigenem SQL ab:
| Aufgabe | Wohnt in | Die API |
|---|---|---|
| Preise, Rundung, Rechnungsnummer | Brandt.Auftragsbuch.Logik |
ruft den Rechner |
| Lesen mit Filter und Seiten | Brandt.Auftragsbuch.Daten, Ordner Abfragen |
ruft die Abfrage |
| Schreiben, das das alte Programm betrifft | Brandt.Auftragsbuch.Daten, Ordner Schutzschicht |
ruft den Schreiber |
| Form der Anfragen und Antworten | Brandt.Auftragsbuch.Vertraege (neu) |
benutzt die Typen |
| HTTP: Routen, Statuscodes, Fehlerformat | Brandt.Auftragsbuch.Api (neu) |
ist diese Schicht |
Die Tabelle hat eine Folge: Wer später eine Preisregel ändert, ändert die Bibliothek, und API, Seite und Windows-Programm rechnen sofort gleich. Wer dagegen in einem Endpunkt „nur mal schnell“ rechnet, hat die dritte Kopie der Regel geschaffen, die Lektion M3.1 gerade beseitigt hat.