Endpoint

Ein Endpoint besteht aus:

1. Methode: GET, POST, PUT, DELETE (Das Verb).
2. Pfad: /api/v1/products/123 (Das Nomen). In Express.js (Node Backend):

app.get('/products/:id', (req, res) => { // Endpoint Definition
  const id = req.params.id;
  // ... Hole Produkt aus DB
});

Der Client ruft auf: GET /products/42.

1. Resource-Oriented Design (REST)

Gute Endpoints sind Nomen, keine Verben. Schlecht: /getAllUsers, /createUser, /deleteUser. (Das ist RPC - Remote Procedure Call). Gut:

• GET /users (Alle holen)
• POST /users (Erstellen)
• DELETE /users/1 (Löschen) Das nutzt die Semantik von HTTP. Endpoints sollten "Ressourcen" repräsentieren, nicht Funktionen.

2. Idempotency Keys

In Distributed Systems (Payment) sind Endpoints kritisch. Ich sende POST /pay (100 Euro). Netzwerk bricht ab. Ich weiß nicht: Hat es geklappt? Ich sende nochmal POST /pay. Ohne Schutz zahle ich 200 Euro. Profi-Endpoints verlangen einen Idempotency-Key: abc-123 Header. Wenn der Server "abc-123" schon kennt, führt er die Zahlung nicht nochmal aus, sondern sendet einfach das alte Ergebnis zurück. Das macht Endpoints robust gegen Retries.

3. HATEOAS

"Hypermedia as the Engine of Application State". (Der komplizierteste Teil von REST). Ein Endpoint liefert nicht nur Daten ({ "name": "Buch" }), sondern auch Links zu nächsten möglichen Endpoints.

{
  "name": "Buch",
  "links": [
    { "rel": "buy", "href": "/products/1/buy" },
    { "rel": "author", "href": "/authors/5" }
  ]
}

Der Client muss die URLs nicht hardcoden, er folgt den Links (wie ein Mensch im Browser). Wird selten implementiert, ist aber der wahre "REST"-Gedanke (Roy Fielding).

1. API-Versioning Architekturen

Apps auf Kunden-Handys werden nicht simultan geupdatet. Wenn dein Backend den Endpoint /api/users aufräumt (Feld first_name fliegt raus), crasht sofort die halbe Flotte der App von "User Hans", der noch Version 1.0 installiert hat und stur den alten Namen erwartet. Lösung ist hartes Versioning.

1. URI-Path Parameter: POST /api/v1/users & POST /api/v2/users. Gut lesbar, aber verstopft oft den Router-Code.
2. HTTP Header (Content Negotiation): Der Client ruft GET /api/users auf, aber der Header enthält Accept: application/vnd.firma.v2+json. Nur hier schaltet der Server das neue JSON-Format frei. Sehr puristisch RESTful, aber oft nervig zu debuggen.

2. N+1 Problem (Underfetching)

Der absolute Fluch klassischer REST Endpoints im Datenbank Backend. Endpunkt A (GET /authors) liefert dir 50 Schriftsteller-IDs. Du willst aber alle Buchtitel von ihnen auf einer Webseite anzeigen. Der Client muss nun für jeden Autor einzeln den Endpunkt B aufrufen (GET /authors/1/books, /authors/2/books...). Ein 50-facher I/O HTTP-Sturm ballert auf dein Backend ein! (Das bekannte N+1 Loop-Problem). Das Problem war so fatal für das Facebook Entwickler-Team, das sie den klassischen REST-Ansatz teils verwarfen und GraphQL erschufen: Ein stark typisierter Mega-Endpoint (POST /graphql), der dem Front-End exakt die Tree-Abfrage erlaubt, die er tiefenverschachtelt braucht.

3. Load Balancing & Sticky Sessions

Hinter der DNS URL deines Shops (api.shop.de/cart) stehen in der Cloud oft 10 Worker-Server in Kubernetes. Ein NGINX NodePort oder ein AWS Elastic Load Balancer jongliert die TCP-Pakete davor in Round-Robin Manier an die 10 Knoten. Du schickst ein Item per POST /cart -> landet auf Server A (fügt es zum lokalen RAM-Cart). Klickst du nochmal (POST /cart), schickt der Balancer das Paket zu Server B. Server B fragt dich: "Welcher Warenkorb?" Endpoints müssen daher prinzipiell Stateless designt werden (Daten liegen in Redis/SQL, nicht im RAM von Server B)! Falls Legacy-Software das erfordert, muss der Ingress-Router eine Sticky Session (Session Affinity) aufbauen, der den Cookie der Node-IP zuweist und den Flow künstlich verbiegt.