04 · From Zero to Deployed

APIs sind die Nahtstellen, an denen Teile einer App — und ganze Firmen — zusammenspielen. Kennst du das Wort, kannst du dem Agenten präzise sagen: „Bau einen Endpunkt, um einen Instagram-Beitrag zu löschen.“

Die Idee

Eine API ist wie eine Speisekarte. Du gehst nicht in die Küche und kochst selbst. Du bestellst aus einer festen Liste, die Küche kümmert sich um den Rest. Die API ist diese Liste an möglichen Bestellungen.

Instagrams App redet die ganze Zeit über so eine Speisekarte mit Instagrams Servern: „gib mir den Feed“, „speichere diesen Beitrag“, „setze ein Like auf Beitrag p_184029“. Du siehst nur schöne Buttons — darunter werden Menüpunkte bestellt.

So funktioniert es

Jeder Menüpunkt heißt Endpunkt — eine bestimmte Anfrage, die das Backend beantworten kann. Kombiniert aus einer Methode und einem Pfad. Eine kleine Instagram-API könnte so aussehen:

GET    /feed             →  Liste der Beiträge holen
POST   /api/posts        →  neuen Beitrag anlegen
POST   /api/posts/:id/like → Beitrag liken
DELETE /api/posts/:id    →  eigenen Beitrag löschen

Der Body eines POST reist als JSON. So legst du einen Beitrag an:

{
  "caption": "Sonnenuntergang über Berlin",
  "imageUrl": "https://cdn.example/p/a1b2.jpg"
}

Und das Backend antwortet mit dem fertigen Objekt, jetzt mit id, author, likeCount und createdAt gefüllt. :id in /api/posts/:id ist ein Platzhalter für eine konkrete Beitrags-ID.

flowchart LR
    A[Instagram-Frontend] -->|POST /api/posts + JSON| B[Backend-API]
    B --> C[(Datenbank)]
    B -->|GET /feed| A

Deine eigene App nutzt ihre eigene API; zusätzlich rufst du fremde APIs auf — für Karten, Zahlungen oder E-Mail bekommst du fertige Fähigkeiten, ohne sie selbst zu bauen. Die meisten modernen Apps sind größtenteils Kleber zwischen APIs.

So steuerst du es

Ressourcen benennt man als Nomen im Plural (/posts, /posts/42), nicht als Verben (/getPost ist schlechter Stil). Neben GET/POST gibt es PUT/PATCH (ändern) und DELETE (löschen). Wichtig: GET darf nichts verändern — sonst löst ein simples Neuladen ungewollt Aktionen aus.

So sagst du es dem Agenten:

„Lege eine kleine JSON-API an: GET /feed liefert alle Beiträge, POST /api/posts legt einen an. Prüfe den Body serverseitig.“

„Füge DELETE /api/posts/:id hinzu; nur der Autor darf löschen, sonst 403.“

„Benenne Endpunkte als Nomen im Plural und lass GET nie Daten verändern.“

Typische Fehler: fehlende Eingabe-Prüfung; kein Statuscode bei Fehlern; Geheimnisse (API-Schlüssel für fremde Dienste) im Frontend statt im Backend.

Kurz-Check

Wofür ist eine API eine gute Analogie?
Was ist der Unterschied zwischen GET /feed und POST /api/posts?
Warum darf GET keine Daten verändern?

Antworten anzeigen

Eine Speisekarte: eine feste Liste an möglichen Anfragen.
GET /feed holt die Beiträge, ohne etwas zu ändern; POST /api/posts legt einen neuen Beitrag an.
Weil Browser und Zwischenspeicher GET-Anfragen jederzeit wiederholen dürfen — Änderungen würden ungewollt mehrfach passieren.

APIs are the seams where parts of an app — and whole companies — connect. Knowing the word lets you tell the agent precisely: "add an endpoint to delete an Instagram post."

The idea

An API is like a menu. You do not walk into the kitchen and cook. You order from a fixed list, and the kitchen handles the rest. The API is that list of possible orders.

Instagram's app talks to Instagram's servers through such a menu all the time: "give me the feed", "save this post", "put a like on post p_184029". You only see nice buttons — underneath, menu items are being ordered.

How it works

Each menu item is an endpoint — a specific request the backend can answer. It combines a method and a path. A small Instagram API might look like this:

GET    /feed             →  fetch the list of posts
POST   /api/posts        →  create a new post
POST   /api/posts/:id/like → like a post
DELETE /api/posts/:id    →  delete your own post

The body of a POST travels as JSON. This is how you create a post:

{
  "caption": "Sunset over Berlin",
  "imageUrl": "https://cdn.example/p/a1b2.jpg"
}

And the backend answers with the finished object, now filled with id, author, likeCount, and createdAt. The :id in /api/posts/:id is a placeholder for a specific post id.

flowchart LR
    A[Instagram frontend] -->|POST /api/posts + JSON| B[Backend API]
    B --> C[(Database)]
    B -->|GET /feed| A

Your own app uses its own API; on top of that you call other APIs — for maps, payments, or email you get ready-made abilities without building them. Most modern apps are mostly glue between APIs.

How you steer it

Name resources as plural nouns (/posts, /posts/42), not verbs (/getPost is poor style). Besides GET/POST there are PUT/PATCH (update) and DELETE (delete). Important: GET must not change anything — otherwise a simple reload would trigger actions by accident.

How to tell the agent:

"Create a small JSON API: GET /feed returns all posts, POST /api/posts creates one. Validate the body on the server."

"Add DELETE /api/posts/:id; only the author may delete, otherwise 403."

"Name endpoints as plural nouns and never let GET change data."

Common mistakes: missing input validation; no status code on failure; secrets (API keys for third-party services) in the frontend instead of the backend.

Quick check

What is a good analogy for an API?
What is the difference between GET /feed and POST /api/posts?
Why must GET not change data?

Show answers

A menu: a fixed list of possible requests.
GET /feed fetches the posts without changing anything; POST /api/posts creates a new post.
Because browsers and caches may repeat GET requests at any time — changes would happen multiple times by accident.

04 · APIs