Was ist eine API? REST vs. SOAP vs. GraphQL

In K50 L8 hast du REST kennengelernt – HTTP-Methoden, Statuscodes, Ressourcen. Dieser Kurs vertieft alles rund um APIs systematisch: in zehn Lektionen lernst du, professionelle REST-APIs zu entwerfen, mit JWT und OAuth2 abzusichern, zu versionieren, gegen Überlastung zu schützen und mit Postman zu testen. Kernkompetenz für FIAEs – ob du ein Backend baust, mit externen Diensten kommunizierst oder selbst eine API bereitstellst.

Diese erste Lektion macht einen Schritt zurück: bevor wir REST vertiefen, klären wir, was eine API überhaupt ist, welche Typen es gibt, und wie sich REST von zwei prominenten Alternativen unterscheidet – SOAP (der Enterprise-Klassiker) und GraphQL (der moderne Herausforderer). Wer diese drei sicher einordnen kann, hat in jeder IHK-Klausur und jedem Architektur-Gespräch einen klaren Vorteil.

1) Was ist eine API überhaupt?

API steht für Application Programming Interface, deutsch: Programmierschnittstelle. Vereinfacht: eine API ist die Schnittstelle, über die ein Programm mit einem anderen reden kann. Ein menschlicher Nutzer kommuniziert über die Benutzeroberfläche (GUI) mit einer Software. Ein anderes Programm kommuniziert über die API.

Eine schöne Alltagsanalogie ist die Steckdose. Du musst nicht verstehen, wie das Kraftwerk funktioniert oder wie der Strom zum Haus gelangt. Du musst nur einen passenden Stecker haben und das vereinbarte „Protokoll" einhalten (230 V Wechselspannung in Deutschland). Genau das macht eine API: sie definiert ein vereinbartes Format für die Kommunikation, hinter dem sich beliebig viel Komplexität verbergen darf. Solange du dich an das Format hältst, funktioniert es.

2) APIs sind überall

Sobald du verstanden hast, was eine API ist, siehst du sie überall. Eine kleine Auswahl der API-Typen, die dir als Entwickler*in begegnen:

3) Web-APIs: warum sie das Internet zusammenhalten

Wenn wir in diesem Kurs „API" sagen, meinen wir ab jetzt vor allem Web-APIs: Schnittstellen, die über das HTTP-Protokoll erreichbar sind. Sie sind die Klebstoff-Schicht des modernen Internets:

• Wenn du eine Wetter-App öffnest, ruft sie eine Wetter-API ab.
• Wenn du dich „mit Google" auf einer Webseite einloggst, läuft das über die OAuth-API von Google (vgl. L6).
• Wenn dein Online-Shop einen Zahlungsdienst nutzt, kommuniziert er über die API von PayPal, Stripe & Co.
• Wenn deine Smartwatch Schlafdaten synchronisiert, geht das per API zur Hersteller-Cloud.
• Wenn dein Backend aus Microservices besteht, reden alle Services untereinander über APIs.

Es gibt im Wesentlichen drei dominante Stile für Web-APIs: REST, SOAP und GraphQL. Schauen wir sie uns nacheinander an – immer am selben Beispiel: „hole Produkt 42 mit Name und Preis".

4) REST: der heutige Standard

REST (Representational State Transfer) ist seit den 2000ern der dominierende Stil für Web-APIs. Du kennst die Grundlagen schon aus K50 L8: Ressourcen mit URLs (Substantive im Plural), HTTP-Verben als Aktion, JSON als Format, Statuscodes für die Antwort.

Die Stärke von REST liegt in seiner Einfachheit: es nutzt direkt die Mechanismen des Webs. Jeder Browser kann eine REST-API ansprechen, jede Programmiersprache hat eingebaute HTTP-Bibliotheken, jeder Entwickler kennt die Grundverben. REST ist kein Standard, sondern ein Architektur-Stil mit Konventionen.

5) SOAP: der Enterprise-Klassiker

SOAP (Simple Object Access Protocol – der Name ist irreführend, denn simpel ist es nicht) stammt aus den späten 1990ern. Es wurde geboren in einer Zeit, in der Software-Schnittstellen extrem streng spezifiziert sein mussten – Banken, Versicherungen, Behörden brauchten formale Garantien.

SOAP nutzt durchgängig XML für alle Nachrichten. Jede Anfrage wird in einen sogenannten Envelope verpackt, mit Header und Body. Das vollständige Schema einer SOAP-API wird in einer eigenen XML-Datei beschrieben – der WSDL (Web Services Description Language). Auf Basis dieser WSDL können Tools automatisch Client-Code generieren – eine schöne Eigenschaft, die in der Enterprise-Welt geschätzt wird.

Vorteile: streng typisiert, mit Schemata validierbar, eingebaute Standards für Transaktionen und Sicherheit (WS-Security). Nachteile: ausführlich (viel Overhead), komplex, schlechte Lesbarkeit. Heute hauptsächlich noch in Banken-, Versicherungs- und Behörden-Schnittstellen anzutreffen.

6) GraphQL: der moderne Herausforderer

GraphQL entstand 2015 bei Facebook und ist der dritte große Stil. Die Grundidee: der Client beschreibt, welche Daten er will, und der Server liefert genau diese Felder – nicht mehr und nicht weniger. Während du bei REST oft mehrere Endpunkte aufrufen musst, um verschachtelte Daten zu bekommen, holst du dir mit GraphQL alles in einer einzigen Anfrage – exakt zugeschnitten.

Eine schöne Analogie: REST ist wie ein Restaurant mit festen Menüs – du bestellst Menü 3 und bekommst Schnitzel mit Pommes, ob du nun die Pommes wolltest oder nicht. GraphQL ist wie ein Buffet – du nimmst dir genau das, was du brauchst, in genau der Menge.

Vorteile: extrem flexibel, ein einziger Endpunkt (/graphql), kein Over- oder Underfetching. Nachteile: Server-seitig deutlich komplexer zu implementieren, Caching ist schwerer als bei REST, manche Tools (z.B. Browser-Cache) verstehen es nicht von Haus aus.

7) Dieselbe Anfrage in allen drei Stilen

Genug Theorie. Schauen wir dasselbe Beispiel in allen drei Stilen: „hole Produkt 42 mit Name und Preis". So sieht das in der Praxis aus:

8) GraphQL live: die Magie der gezielten Abfrage

Der größte Unterschied von GraphQL zu REST ist, dass der Client die Form der Antwort bestimmt. Klick durch die Beispiel-Abfragen und sieh, wie sich die Antwort ändert – obwohl wir immer dasselbe Produkt abrufen:

9) Direktvergleich der drei Stile

Damit du in jeder Klausurfrage und in jedem Architektur-Gespräch sicher zuordnen kannst, hier eine kompakte Gegenüberstellung:

10) Wann welcher Stil? – Entscheidungs-Wizard

In der Praxis hängt die Wahl vom Kontext ab. Klick eine Antwort und sieh, welcher Stil tendenziell passt:

11) Anwendungsbereiche – wo begegnet dir was?

Damit du im Berufsalltag nicht überrascht wirst, hier konkrete Beispiele, wo die drei Stile typisch eingesetzt werden:

12) Begriffsklärungen, die in Klausuren wichtig sind

Zum Schluss ein paar Begriffe, die rund um APIs immer wieder auftauchen – und in IHK-Aufgaben gerne abgefragt werden:

• Endpoint: die URL, unter der eine konkrete API-Funktion erreichbar ist. Z.B. GET /api/products/42.
• Payload: die Nutzdaten in einem Request oder Response, meist im Body. JSON, XML oder anderes.
• Header: Metadaten der HTTP-Nachricht (Content-Type, Authorization, Accept …). Werden in L2 vertieft.
• Stateless: der Server speichert keinen Sitzungszustand zwischen Anfragen – jeder Request muss alle nötigen Informationen mitbringen (Token im Header z.B.).
• Idempotent: mehrfaches Ausführen derselben Operation hat denselben Effekt wie einmaliges. Wichtig bei Netzwerk-Retries. GET, PUT, DELETE sind idempotent, POST nicht.
• API-Gateway: ein vorgeschaltetes System, das Anfragen entgegennimmt, authentifiziert, routet und an interne Services verteilt. Vgl. K50 L7.
• OpenAPI / Swagger: ein offenes Format zur Beschreibung von REST-APIs (das REST-Pendant zu WSDL bei SOAP). Aus einer OpenAPI-Beschreibung können Tools Code, Dokumentation und Test-Suites generieren.

Zusammenfassung

Eine API ist die Programmierschnittstelle, über die ein Programm mit einem anderen kommuniziert – wie eine Steckdose: vereinbartes Format, innere Komplexität verborgen. API-Typen: Web-API, Bibliotheks-API, Betriebssystem-API, Datenbank-API, Hardware-API, Browser-API. Drei dominante Web-API-Stile: REST (heute Standard, Ressourcen + HTTP-Methoden + JSON, einfach), SOAP (Enterprise, XML-Envelope, WSDL, streng typisiert, in Banken/Behörden verbreitet), GraphQL (Client wählt die Felder, ein Endpunkt, ideal für Mobile mit verschachtelten Daten, komplexer zu cachen). Auswahl-Faustregel: neue Web/Mobile-API → REST. Bank-/Behörden-Schnittstelle → meist SOAP vorhanden. Komplexe verschachtelte Frontend-Daten → GraphQL prüfen. Klausur-Begriffe: Endpoint, Payload, Header, Stateless, Idempotent, API-Gateway, OpenAPI/Swagger. Nächste Lektion: HTTP-Methoden und Statuscodes vertieft.