Grundlagen · REST API · HTTP · JSON
Eine API ist eine Schnittstelle, über die Programme miteinander sprechen. Hier lernst du die wichtigsten Begriffe von Grund auf – mit einfachen Beispielen und einer Übung.
1. Was ist eine API?
API bedeutet Application Programming Interface, auf Deutsch Programmierschnittstelle. Sie legt fest, wie eine Anwendung Funktionen oder Daten einer anderen Anwendung nutzen kann. Die API ist ein Vertrag: Sie definiert, welche Anfragen erlaubt sind, welche Daten erwartet werden und welche Antworten zurückkommen. Nicht jede API nutzt HTTP. REST-APIs sind aber besonders häufig, wenn Webanwendungen oder Unternehmenssysteme miteinander kommunizieren.
2. Client, Server und Endpunkt
Der Client ist zum Beispiel ein Browser, eine Smartphone-App oder Microsoft Dynamics 365 Business Central. Der Server stellt die API bereit. Ein Endpunkt ist eine konkrete Adresse, etwa https://api.example.com/api/products. Die Domain bezeichnet den Server; der Pfad /api/products bezeichnet hier die Ressource Produkte. Die Abbildung zeigt den Ablauf einer Anfrage und Antwort.
3. Was ist HTTP?
HTTP ist das Protokoll, über das die Beteiligten ihre Nachrichten austauschen. Eine Anfrage enthält typischerweise eine Methode, eine Adresse, optionale Header und manchmal einen Body. Die Antwort enthält einen HTTP-Status, Header und oft einen JSON-Body. HTTPS verschlüsselt den Transport; für Benutzerberechtigungen ist zusätzliche Authentifizierung und Autorisierung erforderlich.
4. GET, POST, PUT, PATCH und DELETE
GET liest eine Ressource. POST legt meist etwas Neues an oder stößt eine Aktion an. PUT ersetzt einen definierten Ressourcenstand. PATCH verändert ausgewählte Eigenschaften. DELETE entfernt eine Ressource. Die konkrete Bedeutung folgt immer dem dokumentierten API-Vertrag. Ein GET sollte keine Geschäftsaktion mit Seiteneffekten auslösen.
5. Wie sieht eine Anfrage konkret aus?
Dieses Beispiel fragt ein Produkt ab. Der Authorization-Header ist hier nur schematisch dargestellt; verwende nie produktive Tokens in Dokumentation oder Screenshots.
GET /api/products/1 HTTP/1.1
Host: api.example.com
Accept: application/json
Authorization: Bearer YOUR_ACCESS_TOKEN
6. Wie sieht die JSON-Antwort aus?
JSON besteht aus Objekten mit benannten Eigenschaften und aus Arrays. In diesem Beispiel ist id eine Zahl und name eine Zeichenfolge. JSON ist ein Datenformat, keine Datenbank und kein eigener Übertragungsweg.
{
"id": 1,
"name": "Laptop",
"price": 1200.00,
"currency": "EUR"
}
7. Statuscodes verstehen
200 OK steht typischerweise für einen erfolgreichen Abruf. 201 Created zeigt häufig eine erfolgreiche Anlage, 204 No Content eine erfolgreiche Aktion ohne Antwortinhalt. 400 bedeutet eine ungültige Anfrage, 401 fehlende oder ungültige Authentifizierung, 403 fehlende Berechtigung, 404 eine nicht gefundene Ressource und 500 einen Serverfehler. Wichtig: Einen 500-Fehler nicht beliebig oft wiederholen.
8. Sicherheit von Anfang an
Nutze HTTPS, prüfe Zugriffsrechte serverseitig, validiere eingehende Daten und begrenze gegebenenfalls Anfrageraten. API-Schlüssel, Passwörter und Tokens gehören nicht in Quellcode oder öffentliche URLs. Browser-CORS-Einstellungen sind kein Ersatz für Zugriffskontrollen. Für Unternehmens-APIs kann Microsoft Entra ID geeignete Zugriffstokens bereitstellen.
9. Selbst ausprobieren
Öffne ein Terminal und führe den folgenden Befehl gegen eine von dir betriebene Test-API aus. -i zeigt auch die Header und den Status. Wenn du noch keine API hast, folgt im nächsten Tutorial der Aufbau einer eigenen ASP.NET-Core-API.
curl -i https://localhost:5001/api/products
10. Wann braucht Business Central eine API?
Business Central kann über HTTP mit anderen Systemen kommunizieren, etwa um Versandlabels abzurufen, Dokumente ans DMS zu übertragen oder Daten für einen Webshop bereitzustellen. Prüfe zunächst, ob eine vorhandene Standard-API den Geschäftsfall schon unterstützt. Bei individuellen Prozessen können eigene AL-APIs oder Azure Functions sinnvoll sein.
11. Häufige Anfängerfehler
Ein Browser-Test beweist noch nicht, dass POST, Autorisierung oder Fehlerbehandlung funktionieren. Verwechsle eine API-Adresse nicht mit der Website-Oberfläche. Nimm nicht an, dass jede erfolgreiche HTTP-Antwort eine fachlich abgeschlossene Verarbeitung bedeutet. Dokumentiere Request- und Response-Beispiele, Datentypen, mögliche Fehler und Versionen.
12. Nächste Schritte
Im Anschluss erstellen wir eine eigene .NET-API mit zwei Endpunkten und testen sie über curl. Danach folgen Datenbankanbindung, Eingabevalidierung, OAuth-Berechtigungen und die Anbindung an Business Central.
Kommentare (0)
Noch keine Kommentare. Schreibe den ersten Beitrag zur Diskussion.