Was ist eine API? Programmierschnittstelle einfach erklärt mit Beispielen

Was ist eine API?

Eine API, kurz für Application Programming Interface, ist eine Programmierschnittstelle mit festen Regeln, über die ein Programm mit einem anderen Programm spricht. Konkret legt sie fest, welche Anfragen Sie senden dürfen und welche Antwort zurückkommt. Somit arbeiten zwei Systeme zusammen, ohne ihr Innenleben zu kennen.

Denken Sie an eine Steckdose. Sie liefert Strom für Ihre Lampe, denn Sie müssen nicht wissen, wie das Kraftwerk funktioniert. Eine API ist genau so eine Steckdose für Software. Dann lernen Sie nur die Form des Steckers und die Regeln, mehr brauchen Sie nicht.

In diesem Leitfaden erklären wir, was eine API ist, in einfacher Sprache. Zunächst bauen wir die Idee mit einem Restaurant Vergleich auf. Danach folgen Anfrage, Antwort, Endpunkt, HTTP Methoden und Statuscodes. Schließlich finden Sie API Typen, Alltagsbeispiele, Grenzen und eine Checkliste für Unternehmen.

Wie erklärt ein Restaurant, was eine API ist?

Stellen Sie sich ein Restaurant vor. Köche bereiten das Essen in der Küche zu, aber Sie betreten die Küche nie. Dann halten Sie eine Speisekarte in der Hand, wählen ein Gericht und sagen es dem Kellner. Der Kellner bringt die Bestellung in die Küche und serviert Ihnen später den Teller.

Jeder Teil dieser Szene hat ein Gegenstück in der Software:

• Sie sind der Client, zum Beispiel eine mobile App oder eine Website.
• Die Speisekarte ist die API Dokumentation. Zum Beispiel zeigt sie, welche Anfragen möglich sind.
• Der Kellner ist die API selbst. Kurz gesagt nimmt er Ihre Anfrage entgegen, bringt sie an die richtige Stelle und liefert die Antwort zurück.
• Die Küche ist der Server, der Daten und Geschäftslogik enthält.
• Das Gericht ist die Antwort, die bei Ihnen ankommt.

Bestellen Sie etwas, das nicht auf der Karte steht, kann der Kellner es nicht liefern. Ebenso beantwortet eine API nur definierte Anfragen. Diese Grenze schützt, denn nicht jeder darf in die Küche.

Wie laufen Anfrage und Antwort bei einer API ab?

Ein API Aufruf besteht aus zwei Teilen: Anfrage und Antwort. Zunächst sendet der Client die Anfrage, danach liefert der Server die Antwort. Dieser Kreislauf dauert oft nur einen winzigen Bruchteil einer Sekunde, deshalb bemerken Nutzer ihn kaum.

Eine Anfrage enthält in der Regel diese Angaben:

• Eine Zieladresse, die sagt, welche Ressource Sie erreichen möchten.
• Eine Methode, die sagt, was Sie tun wollen, etwa lesen, hinzufügen oder löschen.
• Kopfzeilen mit Zusatzinfos, zum Beispiel wer fragt und welches Format Sie erwarten.
• Bei Bedarf einen Körper, der die gesendeten Daten enthält.

Dagegen enthält eine Antwort einen Statuscode, Kopfzeilen und oft einen Datenkörper. Zum Beispiel senden Sie einen Städtenamen an eine Wetter API. Dafür erhalten Sie dann Temperatur und Luftfeuchtigkeit zurück.

Also beruhen alle diese Regeln auf dem Protokoll HTTP. Die RFC 9110 der IETF definiert, was HTTP bedeutet. Die MDN Dokumentation zu HTTP erklärt dieselben Ideen mit praktischen Beispielen.

Was ist eine API Anfrage in der Praxis und wie läuft sie von Anfang bis Ende?

Folgen wir einem konkreten Beispiel. Zunächst möchte ein Kunde auf der Bestellseite sehen, wo sein Paket gerade ist. Im Hintergrund passiert Folgendes:

1. Der Kunde öffnet die Seite, und der Browser kontaktiert Ihren Server.
2. Ihr Server bereitet eine Leseanfrage an die API des Versanddienstes vor und fügt Sendungsnummer und Schlüssel hinzu.
3. Der Server des Versanddienstes prüft den Schlüssel und sucht die Sendungsnummer in seinem System.
4. Findet er einen Eintrag, liefert er den Code 200 und den Sendungsstatus als JSON.
5. Dann liest Ihr Server die Daten und setzt sie auf die Seite.
6. Der Kunde sieht einen Status wie "In Zustellung", ohne etwas zu bemerken.

Diese Kette zeigt, was eine API in der Praxis ist: ein Vertrag zwischen zwei Systemen. Zudem wissen Sie nicht, was im Versanddienst passiert, und der Dienst kennt Ihre Seite nicht. Stattdessen tauschen Sie Nachrichten aus, die dem Vertrag folgen.

Zum Beispiel kommt bei einer falschen Sendungsnummer ein 404. Ist der Schlüssel ungültig, kommt ein 401. Fällt der Server des Dienstes aus, kommt ein 500. Deshalb bereitet ein gutes System für jeden Fall eine klare Meldung vor.

Was ist ein Endpunkt und wie lesen Sie eine API Adresse?

Ein Endpunkt ist die Adresse, über die eine API eine bestimmte Ressource anbietet. Kurz gesagt funktioniert er wie eine Tür, und jede Tür führt in einen anderen Raum. Zum Beispiel kann eine Adresse Bestellungen liefern, eine andere Kunden.

Außerdem hat eine Adresse meistens drei Teile. Zuerst kommt die Domain, etwa example.com, die den Server benennt. Dann folgt der Pfad, der sagt, welche Ressource Sie wollen. Zuletzt stehen optionale Parameter, also Filter, die das Ergebnis eingrenzen.

Außerdem sind Ressourcennamen oft Substantive im Plural. Daher können Sie meist erraten, was eine Adresse zurückgibt. Eine Kundenliste liegt unter einem Pfad, ein einzelner Kunde unter demselben Pfad plus Kennnummer.

In einer gut durchdachten API sind Adressen vorhersehbar. Folglich müssen Sie nicht jedes Mal die Dokumentation öffnen. In einer schlampigen API finden Sie dagegen drei Adressen für dieselbe Aufgabe, und das erhöht das Fehlerrisiko.

Was bedeuten die HTTP Methoden bei einer API?

Die Methode nennt die Absicht der Anfrage. Vor allem in Web APIs sind vier Methoden sehr verbreitet. Man kann sie mit einem Aktenschrank vergleichen: Eine Akte herausnehmen, hinzufügen, ersetzen und wegwerfen sind vier verschiedene Handlungen.

Diese Zuordnung ist eher eine Konvention als ein Gesetz, aber die meisten Teams halten sich daran. Außerdem verändern Methoden wie GET keine Daten. Das heißt, Sie dürfen dieselbe Anfrage gefahrlos mehrfach senden.

Wenn eine Wiederholung das Ergebnis nicht ändert, spricht man von Idempotenz. Wir erklären sie im Beitrag was ist Idempotenz. Die offiziellen Definitionen finden Sie auf der MDN Seite zu den HTTP Methoden.

Wie beschreiben Statuscodes die Antwort einer API?

Zunächst beginnt jede Antwort mit einem dreistelligen Statuscode. Daher zeigt der Code auf einen Blick, wie die Aufgabe ausging. Zudem kommen die Codes in Hunderter Gruppen, und die erste Ziffer verrät die Art des Ergebnisses.

Der wichtige Unterschied lautet: 4xx Codes zeigen meist auf etwas, das der Absender korrigieren muss. 5xx Codes sagen dagegen, dass das Problem auf dem Server liegt. Beim Fehlersuchen schauen Sie daher zuerst auf die erste Ziffer.

Die offizielle Liste finden Sie auf der MDN Seite zu den Statuscodes. Zu zwei häufigen Fehlern lesen Sie unsere Beiträge zum Fehler 401 Unauthorized und zum Fehler 500 Internal Server Error.

In welchem Format transportiert eine API Daten?

Web APIs übertragen Daten als Text, und das häufigste Format ist JSON, kurz für JavaScript Object Notation. JSON ist eine lesbare Struktur aus Schlüsseln und Werten. Menschen lesen sie leicht, und Maschinen verarbeiten sie ebenso leicht.

Zum Beispiel kommt ein Kundendatensatz als kleiner Text mit den Feldern Name, E-Mail und Stadt. Konkret hat jedes Feld einen klaren Namen, und der Wert steht daneben. Dank dieser Struktur weiß der Empfänger, welche Information wo steht.

Manche ältere oder große Systeme nutzen XML. Außerdem tauchen bei der Dateiübertragung auch binäre Formate auf. Trotzdem ist JSON für Einsteiger ein solider Anfang.

Zudem nennen die Kopfzeilen den Inhaltstyp der Daten. Somit weiß der Empfänger, wie er den Text lesen soll. Dieses kleine Detail ist wichtiger, als man denkt, wenn sich zwei Systeme einigen müssen.

Wie hängen Frontend und Backend über eine API zusammen?

Eine Webanwendung hat zwei Schichten: das Frontend, das Nutzer sehen, und das Backend, das Daten verarbeitet. Kurz gesagt ist die API die Brücke dazwischen. Während das Frontend einen Bildschirm zeichnet, fragt es die API nach den nötigen Daten.

Deshalb bringt diese Trennung einen großen Vorteil. Eine Website, eine mobile App und ein Partnersystem können dieselbe API nutzen. Daher erzeugen Sie die Daten nur einmal und sehen überall dasselbe Ergebnis.

Die Nutzerseite erklären wir im Beitrag was ist Frontend Entwicklung. Die Serverseite behandelt der Beitrag was ist ein Backend. Teams bauen beide Seiten oft parallel anhand des API Vertrags, sodass keiner auf den anderen wartet.

Warum brauchen APIs Schlüssel und Authentifizierung?

Allerdings steht nicht jede API allen offen. Der Server will wissen, wer die Anfrage sendet und was der Absender darf. Das sind zwei getrennte Fragen: Authentifizierung klärt, wer Sie sind, und Autorisierung klärt, worauf Sie zugreifen dürfen.

Die einfachste Methode ist ein API Schlüssel. In der Praxis ist er eine lange, nicht erratbare Zeichenfolge, die bei jeder Anfrage mitreist. Ein Schlüssel wirkt wie ein Zugangsausweis: Er öffnet die Haupttür, doch welche Räume Sie betreten dürfen, steht separat fest.

Flexiblere Lösungen setzen auf Token:

• OAuth 2.0 erlaubt einem Nutzer, einer anderen App begrenzten Zugriff zu geben, ohne ein Passwort zu teilen.
• JWT trägt Identitätsdaten in einem signierten Token.
• Sitzungscookies sind in browserbasierten Anwendungen üblich.

Daher legen Sie einen Schlüssel nie auf eine öffentliche Seite oder in ein App Paket. Ein durchgesickerter Schlüssel öffnet jedem die Tür, der in Ihrem Namen Anfragen senden will. Außerdem sollten Sie Schlüssel regelmäßig erneuern.

Welche Arten von APIs gibt es und wie unterscheiden sie sich?

Zunächst bezeichnet das Wort API nicht eine einzelne Technik, sondern ein breites Konzept. Im Alltag meinen wir meist Web APIs, aber es gibt auch Bibliotheks und Betriebssystem APIs. Daher hilft es, zuerst die Art zu klären.

Dieser Leitfaden konzentriert sich auf Web APIs, weil Unternehmen ihnen am häufigsten begegnen. Dennoch folgt eine Bibliotheks API derselben Logik: Sie rufen eine fertige Funktion nach festen Regeln auf.

Was ist eine REST API und warum ist sie so verbreitet?

Zunächst: REST ist ein Architekturstil für Web APIs. Er benennt Ressourcen mit Adressen, führt Aktionen mit HTTP Methoden aus und behandelt jede Anfrage für sich. Das heißt, der Server muss sich Ihre vorige Anfrage nicht merken.

Für die Verbreitung gibt es mehrere Gründe. Erstens läuft HTTP bereits überall, deshalb brauchen Sie kein Zusatzwerkzeug. Zweitens sind Adressen und Methoden lesbar, und Neulinge lernen sie schnell. Drittens ist ein Client in jeder Sprache leicht zu schreiben.

REST ist eine Denkweise, kein strenger Standard. Folglich können zwei REST APIs recht unterschiedlich aussehen. Diese Freiheit ist ein Vorteil, kann aber auch Uneinheitlichkeit erzeugen.

Wenn Sie die Schichten hinter einer API kennenlernen möchten, lesen Sie unseren Beitrag was ist ein Backend.

Wann kommen GraphQL oder gRPC infrage?

Allerdings ist REST nicht immer ideal. Angenommen, ein Handybildschirm braucht nur drei Felder, doch die REST Antwort liefert zehn. Das verschwendet also Datenverkehr. Hier hilft GraphQL: Der Client nennt genau die gewünschten Felder und erhält nur diese.

Vor- und Nachteile erklären wir im Beitrag GraphQL im Vergleich zu REST. Kurz gesagt wird GraphQL attraktiv, wenn mehrere Clients unterschiedliche Daten brauchen.

gRPC eignet sich für schnelle Gespräche zwischen Diensten. Dazu verpackt es Daten binär, sodass Nachrichten klein bleiben. Deshalb sieht man es oft in großen Systemen, vor allem bei Teams mit einer Microservices Architektur.

Trotzdem ist für Einsteiger die Reihenfolge einfach. Lernen Sie zunächst REST gründlich. Danach wechseln Sie zu den anderen beiden, sobald ein echter Bedarf entsteht.

Was unterscheidet öffentliche, private und Partner APIs?

APIs unterscheiden sich auch danach, wer sie erreichen darf. Denn diese Einteilung entscheidet, wer unter welchen Bedingungen auf welche Daten zugreift. Daher gehört sie zu den ersten Fragen, wenn Sie eine API wählen oder anbieten.

Private APIs sind oft die größte Gruppe, doch von außen sieht sie niemand. Die mobile App eines Unternehmens spricht meist über eine private API mit dem eigenen Server.

Eine öffentliche API kann einen neuen Vertriebskanal für Ihr Produkt schaffen. Allerdings bringt sie auch Verantwortung mit. Dokumentation, Support, Versionierung und Sicherheit nehmen zu.

Was ist eine API im Alltag und wo begegnen Sie ihr?

Tatsächlich nutzen Sie APIs jeden Tag, ohne es zu merken. Die folgenden Beispielszenarien zeigen dieselbe Logik in verschiedenen Rollen:

• Karte einbetten: Eine Firmenwebsite zeigt den Standort der Filiale auf einer Karte. Die Seite sendet den Ort an die API des Kartendienstes und erhält das Bild zurück.
• Zahlung: Zahlt ein Kunde per Karte, sendet die Seite Betrag und Bestelldaten an die API des Zahlungsanbieters. Dann meldet der Anbieter das Ergebnis, und die Seite bestätigt die Bestellung.
• Sendungsverfolgung: Der Paketstatus auf der Bestellseite stammt aus der API des Versanddienstes. Bei jedem Aufruf kommen frische Daten an.
• Wetter: Die App auf Ihrem Handy fragt einen Datendienst nach Ihrem Standort und zeigt die Temperatur an.

Das sind erdachte Szenarien, aber sie spiegeln das Verhalten echter Systeme. Konkret ist der gemeinsame Kern einfach. Wenn Sie ein Produkt bauen, erledigen Sie nicht jede Aufgabe von Grund auf. Stattdessen leihen Sie sich die Arbeit eines Spezialdienstes über dessen API.

Wenn Sie die Zahlungsseite planen, hilft Ihnen unser Beitrag Zahlungsanbieter für Onlineshops auswählen.

Was ist ein Rate Limit und warum begrenzen APIs die Anfragen?

Ein Rate Limit ist eine Obergrenze dafür, wie viele Anfragen Sie in einer bestimmten Zeit senden dürfen. Überschreiten Sie sie, antwortet der Server meist mit dem Code 429 und bittet Sie zu warten. Das gleicht einer Küche, die nur eine bestimmte Zahl an Bestellungen gleichzeitig annehmen kann.

Dafür gibt es mehrere Gründe. Erstens schützt sie den Server vor Überlastung. Zweitens verhindert sie, dass ein fehlerhafter oder böswilliger Client allen anderen das Erlebnis verdirbt. Drittens verteilt sie Ressourcen fair.

Als Entwickler sollten Sie sich diese Gewohnheiten aneignen:

• Speichern Sie eine Antwort eine Weile, statt dieselben Daten immer wieder abzufragen.
• Wiederholen Sie nach einem Fehler nicht sofort, sondern warten Sie bei jedem Versuch etwas länger.
• Lesen Sie die Grenzwerte in der Dokumentation, denn sie unterscheiden sich je nach Dienst, und aktuelle Werte stehen nur auf der Seite des Anbieters.

Wir nennen hier keine Zahlen, weil Kontingente und Limits von Anbieter zu Anbieter wechseln. Prüfen Sie die aktuellen Werte immer in der offiziellen Dokumentation.

Warum ist die Versionierung einer API wichtig?

Zunächst gilt: Sobald eine API live ist, verlassen sich die Apps, die sie nutzen, auf sie. Benennen Sie ein Feld um oder brechen Sie das Antwortformat, können diese Apps ausfallen. Versionierung ist der Weg, dieses Risiko zu steuern.

Daher ist die Logik einfach. Braucht es eine grundlegende Änderung, veröffentlichen Sie eine neue Version und lassen die alte noch eine Weile laufen. Somit wechseln Clients in ihrem eigenen Tempo. Die Versionsnummer steht meist in der Adresse oder in einer Kopfzeile.

Eine gute Versionierungsrichtlinie umfasst drei Dinge:

1. Legen Sie fest, welche Änderungen abwärtskompatibel sind und welche nicht.
2. Kündigen Sie die Abschaltung einer alten Version klar und mit genügend Vorlauf an.
3. Halten Sie das Änderungsprotokoll in der Dokumentation sichtbar.

Kurz gesagt ist Versionierung die Garantie hinter Ihrem Versprechen. Wer auf Ihrer API aufbaut, will morgens aufwachen und wissen, dass sein System nicht über Nacht kaputtgeht.

Was ist eine API Dokumentation und wofür steht OpenAPI?

Die API Dokumentation ist die Speisekarte der API. Sie beschreibt die Adressen, die nutzbaren Methoden, die Pflichtfelder und die möglichen Fehler. Tatsächlich ist eine gute Dokumentation die halbe API wert.

OpenAPI ist eine Spezifikation, die REST APIs in maschinenlesbarer Form beschreibt. Damit ist die Dokumentation nicht mehr nur ein Text für Menschen. Werkzeuge lesen die Beschreibung und erzeugen interaktive Dokumente, Tests und sogar Clientcode.

Die offizielle Quelle der Spezifikation ist die Website der OpenAPI Initiative. Wenn Sie mit einer API arbeiten wollen, prüfen Sie, ob sie eine OpenAPI Beschreibung anbietet. Das spart außerdem viel Zeit.

Einen ähnlichen Bedarf gibt es bei KI. Ein Modell muss wissen, welche Werkzeuge es aufrufen darf. Das beschreiben wir im Beitrag was ist Function Calling.

Wie unterscheiden sich API, SDK, Webhook und Integration?

Diese vier Begriffe werden oft vermischt, weil alle Systeme verbinden. Allerdings spielt jeder eine andere Rolle. Die folgende Tabelle zeigt den Unterschied auf einen Blick.

Ein Unterschied zählt besonders. Bei einer API fragen Sie, bei einem Webhook bekommen Sie Bescheid. Statt also ständig nach einer Bestellung zu fragen, warten Sie auf eine Nachricht bei Statuswechsel. Das senkt unnötige Anfragen.

Schließlich ist Integration der weiteste Begriff. Eine Integration kann API, Webhook und Datenumwandlung zugleich umfassen. Beispiele für Unternehmen finden Sie im Beitrag Website Integration mit CRM, ERP und Chatbot.

Welche Risiken bringt die Nutzung einer API mit sich?

APIs entlasten Ihre Arbeit, bringen aber auch neue Risiken. Daher vermeidet, wer sie früh kennt, spätere Überraschungen.

• Abhängigkeit: Hängt ein wichtiger Ablauf an einem externen Dienst, steht Ihre Arbeit still, sobald der Dienst ausfällt.
• Sicherheit: Durchgesickerte Schlüssel, zu weite Rechte und ungeschützte Adressen können Daten offenlegen.
• Änderung: Entfernt der Anbieter ein Feld oder ändert sein Verhalten, kann Ihr Code brechen.
• Datenschutz: Senden Sie personenbezogene Daten an einen externen Dienst, müssen Sie die rechtlichen und vertraglichen Bedingungen dieses Datenflusses kennen.
• Kosten: Bei Diensten mit Abrechnung pro Anfrage führt unkontrollierte Nutzung zu unerwarteten Rechnungen.

Dennoch gibt es gegen jedes dieser Risiken ein Mittel. Zum Beispiel ergänzen Sie Zeitlimits und Wiederholungslogik, halten Rechte minimal und überwachen die Nutzung. Außerdem prüfen Sie die Sicherheit einer Verbindung mit unserem SSL Check.

Bei Integrationen mit personenbezogenen Daten holen Sie rechtlichen Rat ein. Dieser Beitrag ersetzt keine Rechtsberatung.

Wie starten Sie mit einer API?

Also verstehen Sie eine API am besten, wenn Sie eine kleine Anfrage selbst beobachten. Sie können sogar ohne Code beginnen, denn die Adresszeile des Browsers sendet eine einfache Leseanfrage. Gehen Sie in dieser Reihenfolge Schritt für Schritt vor:

1. Wählen Sie eine einfache, offene API. Ein Beispieldienst ohne Schlüssel ist ideal.
2. Lesen Sie die Dokumentation und suchen Sie einen Endpunkt.
3. Senden Sie die Anfrage mit einem Werkzeug oder dem Browser und prüfen Sie die Antwort.
4. Notieren Sie Statuscode und Datenfelder.
5. Senden Sie absichtlich eine falsche Anfrage und sehen Sie, wie eine Fehlerantwort aussieht.
6. Wiederholen Sie danach dieselbe Anfrage aus Ihrem eigenen Programm.

Somit sehen Sie bei jedem Schritt genau, was sich ändert. Wenn Sie neu in der Programmierung sind, sollte Ihr erstes Ziel eine einzige funktionierende Anfrage sein. Komplizierte Authentifizierung kann dagegen warten.

Wenn Sie KI Dienste ausprobieren möchten, finden Sie dort dieselbe Logik. Unsere Anleitung zur OpenAI API ist ein guter Einstieg.

Was gehört in die Checkliste für eine API Integration im Unternehmen?

Bevor Sie eine API an Ihr Produkt anbinden, wägen Sie technische und geschäftliche Seite gemeinsam ab. Die folgende Liste gibt Ihnen einen praktischen Rahmen für die Entscheidung:

1. Formulieren Sie das Ziel: Welches Geschäftsproblem löst die API, und wie messen Sie den Erfolg?
2. Prüfen Sie die Dokumentation: Ist sie aktuell, gibt es Beispiele, und erklärt sie Fehlerantworten?
3. Klären Sie die Authentifizierung und entscheiden Sie, wo Sie Schlüssel aufbewahren.
4. Prüfen Sie Nutzungsgrenzen und Preislogik auf der offiziellen Seite des Anbieters.
5. Fragen Sie nach Versionierung und der Richtlinie zur Abschaltung alter Versionen.
6. Fließen personenbezogene Daten, prüfen Sie Datenschutz und Vertragsbedingungen.
7. Planen Sie den Ausfall: Was sieht der Nutzer, wenn der Dienst nicht läuft?
8. Klären Sie, ob es eine Testumgebung (Sandbox) gibt, und probieren Sie dort, bevor Sie live gehen.
9. Richten Sie Überwachung ein: Beobachten Sie Fehlerquote und Verzögerung.
10. Bewerten Sie Ihre Abhängigkeit vom Anbieter und bereiten Sie bei Bedarf einen Ausweichplan vor.

Wer diese Liste zu Projektbeginn ausfüllt, senkt teure Änderungen später. Brauchen Sie eine individuelle Integration oder neue Software, erreichen Sie uns über die Seite zur individuellen Softwareentwicklung.

Welche Irrtümer rund um APIs sind am häufigsten?

Allerdings kehren einige Missverständnisse zu APIs ständig wieder. Wer sie früh klärt, lernt schneller.

• "Eine API ist eine Datenbank." Nein, eine API ist eine Tür. Zum Beispiel kann dahinter eine Datenbank liegen, aber die API selbst speichert nichts.
• "Eine API und eine Website sind dasselbe." Nein, eine Website zeigt einem Menschen Bilder. Eine API liefert einer Software Daten.
• "APIs sind immer kostenlos." Nein, manche sind gratis, andere rechnen nach Nutzung ab. Prüfen Sie die aktuellen Bedingungen beim Anbieter.
• "Ein API Schlüssel ist ein Passwort, das man teilen kann." Nein, ein Schlüssel ist privat und muss geheim bleiben.
• "REST ist die einzige Art von API." Nein, es gibt auch GraphQL, gRPC und Bibliotheks APIs.

Also entstehen die meisten dieser Irrtümer, weil eine API abstrakt ist. Weil sie keinen Bildschirm hat, fällt der Vergleich mit etwas Greifbarem schwer. Die Bilder von Restaurant und Steckdose füllen genau diese Lücke.

Was ist eine API in einem kurzen Fazit?

Eine API ist der Vertrag, über den Software mit anderer Software nach festen Regeln spricht. Der Client sendet eine Anfrage, der Server liefert eine Antwort. Diese Antwort kommt mit einem Statuscode und trägt meist Daten im Format JSON.

Merken Sie sich diese Punkte: Der Endpunkt ist die Adresse, die Methode ist die Absicht, der Statuscode ist das Ergebnis. Schlüssel und Token bestätigen die Identität, Rate Limits schützen Ressourcen, und Versionierung sichert die Kompatibilität. Web, Bibliotheks und Betriebssystem APIs sind verschiedene Arten.

Für ein Unternehmen ist der kluge Einsatz von APIs schneller und sicherer, als alles selbst zu schreiben. Lesen Sie die Dokumentation, wägen Sie die Risiken ab und verzichten Sie nie auf Überwachung. Zu benachbarten Themen lesen Sie unsere Beiträge zu OAuth 2.0 und zu IaaS, PaaS und SaaS.

Technische Details entwickeln sich zwar weiter, aber die Grundlogik einer API bleibt gleich. Deshalb lohnt es sich langfristig am meisten, das Konzept zu verstehen und nicht Produktversionen oder Zahlen.