RESTful APIs – JSON‑Kommunikation

Erste Schritte: RESTful APIs – JSON‑Kommunikation & Micro‑Service‑Strukturen

Moderne Web‑Apps bestehen oft aus einem JavaScript‑Frontend (Vue, React, Svelte …)
und einem oder mehreren „headless“ Backends, die ausschließlich RESTful APIs bereitstellen.
Bei REST (Representational State Transfer) werden Ressourcen über klare HTTP‑Verben
(GET, POST, PUT/PATCH, DELETE) adressiert und Daten fast immer als JSON übertragen.
Hier lernst du, wie du in PHP eine einfache API entwirfst, JSON korrekt lieferst
und wie das Konzept in einer Micro‑Service‑Landschaft aussieht.

1. Ressourcen & Endpunkte modellieren

Ressource URL‑Beispiel GET POST PUT/PATCH DELETE
/tasks /api/tasks Liste Neu
/tasks/{id} /api/tasks/42 Einzel Update Löschen

2. JSON‑Antwort & HTTP‑Header

<?php
header('Content-Type: application/json; charset=utf-8');
http_response_code(200);

echo json_encode([
  'data' => [
    'id'    => 42,
    'title' => 'JSON lernen',
    'done'  => false
  ]
], JSON_UNESCAPED_UNICODE | JSON_PRETTY_PRINT);
?>
  • Content‑Type: application/json.
  • http_response_code – 200 (OK), 201 (Created), 404 (Not Found) …
  • JSON_UNESCAPED_UNICODE – Umlaute/Emoji bleiben lesbar.

3. Slim‑Router‑Snippet (Micro‑API)

$app->get('/api/tasks', function ($req, $res) {
    $tasks = Task::all();
    return $res->withJson($tasks);
});

$app->post('/api/tasks', function ($req, $res) {
    $data = $req->getParsedBody();
    $task = Task::create($data);
    return $res->withJson($task, 201);
});

Slim (oder phpFK mit eigenem Router) leitet HTTP‑Methoden direkt auf Callbacks.

4. Authentifizierung – Token (z. B. JWT)

Authorization: Bearer eyJhbGciOiJIUzI1NiIsInR5cCI6IkpXVCJ9...
  • Frontend loggt sich über /api/login ein, erhält JWT‑Token.
  • Backend prüft Token in jeder Anfrage (Middleware).

5. Paginierung & Filter als Query‑Parameter

GET /api/tasks?page=2&status=open

Antwort‑Header (Link) oder Body‑Meta geben page, per_page, total aus.

6. Fehler‑Format (RFC 7807  “Problem Details”)

HTTP/1.1 400 Bad Request
Content-Type: application/problem+json

{
  "type":   "https://example.com/validation-error",
  "title":  "Your request parameters didn't validate.",
  "status": 400,
  "errors": {
    "title": "Das Feld ist erforderlich."
  }
}

7. Micro‑Services – Trennung nach Domänen

  • Service A / User‑API – verwaltet Auth & Profile.
  • Service B / Task‑API – CRUD für Aufgaben.
  • Service C / Notification – verschickt Mails, Webhooks.

Kommunikation untereinander per REST oder Queue (RabbitMQ, SQS).
Gatekeeper (API Gateway oder Nginx Proxy) bündelt nach außen.

8. Load‑Testing (Performance)

# 100 gleichzeitige Nutzer, 1000 Requests
ab -n 1000 -c 100 https://api.example.com/tasks

Beobachte Antwortzeiten & Durchsatz, skaliere horizontal (Docker Swarm, Kubernetes) bei Bedarf.

9. Best Practices

  1. Konsistente JSON‑Struktur { data: …, meta: … }.
  2. Ressourcen‑URLs als Self‑Links zurückgeben (HATEOAS light).
  3. Nutze HTTP‑Statuscodes korrekt (422 Validation, 409 Conflict).
  4. Versioniere API / v1, v2 – eigener Namespace oder Accept‑Header.
  5. CORS‑Header setzen, wenn Frontend auf fremdem Origin liegt.

Fazit

RESTful APIs mit JSON sind der Klebstoff moderner Micro‑Service‑Architekturen.
Klar definierte Endpunkte, saubere Statuscodes und Token‑Auth bilden die Basis.
Durch Separierung in kleine Services gewinnst du Skalierbarkeit –
achte aber auf konsistente Fehler­formate und automatisiertes API‑Testing,
damit die vielen Bausteine stabil zusammenspielen.