Konsolidierung fehlender Endpunkte für Remote-Backend-Frontend (notwendig vs. wünschenswert)

[skerbis]

Kontext

Bei der Entwicklung eines Remote-Backend-Frontends für REDAXO (Control-Plane über API) ist aufgefallen, dass mehrere zentrale Betriebs- und Daten-Endpunkte fehlen.

Im aktuellen Stand sind Core-CRUD-Endpunkte (Structure/Media/Templates/Modules/Users/Clangs/Metainfo) vorhanden, aber für den produktiven Remote-Betrieb fehlen wichtige API-Bausteine.

---

Notwendig (MVP)

1) Addon-Management

• GET /addons — Addon-Liste inkl. installed/active Status
• GET /addons/{id} — Addon-Details (Version, Requirements, Dependencies)
• PATCH /addons/{id}/status — aktivieren/deaktivieren

2) Addon Lifecycle

• POST /addons/{id}/install
• POST /addons/{id}/uninstall
• POST /addons/{id}/activate
• POST /addons/{id}/deactivate
• POST /addons/{id}/upgrade

3) Cache-Management

• GET /cache/status — Größe/Status/Last-Rebuild
• DELETE /cache/all
• DELETE /cache/{type} — z. B. db, templates, packages

4) System-Information / Betrieb

• GET /system/info — PHP/REDAXO/Basisinfos
• GET /system/disk — Disk Space
• GET /system/database — DB-Größe/Tabellenanzahl
• GET /system/health — Basis-Healthcheck

5) YForm API (für datengetriebene Remote-Backends essenziell)

• GET /yform/tables
• GET /yform/tables/{table}
• GET /yform/tables/{table}/fields
• GET /yform/tables/{table}/records
• GET /yform/tables/{table}/records/{id}
• POST /yform/tables/{table}/records
• PATCH /yform/tables/{table}/records/{id}
• DELETE /yform/tables/{table}/records/{id}

---

Wünschenswert (Ausbau)

Addon Ops / UX

• GET /addons/{id}/health — Readiness/Requirement-Check
• POST /addons/{id}/setup/check — Preflight vor Install/Aktivierung
• GET /addons/{id}/logs — letzte Install/Update-Logs

YForm Komfort-Endpunkte

• GET /yform/tables/{table}/options/{field} — Select/Choice-Optionen
• GET /yform/lookups/{table} — Lightweight-Lookups (id + label)
• POST /yform/tables/{table}/validate — Payload validieren ohne Persistenz

Optional für Betrieb

• Erweiterter Healthcheck mit Teilstatus (db, filesystem, cache, addons)
• Einheitliche Betriebs-Metriken für Dashboard-Kacheln

---

Anforderungen (für alle neuen Endpunkte)

• Einheitliches Response-Schema (wie bestehende API)
• Saubere Fehlercodes (400, 403, 404, 409, 422, 500)
• Klare Admin-Berechtigung für mutierende Operationen (POST/PATCH/DELETE)
• Konsistentes Paging/Sorting/Filtering bei Listen

---

Warum Priorität

Diese Lücken sind im praktischen Aufbau eines Remote-Backends direkt aufgetreten.
Ohne diese Endpunkte bleibt das Dashboard zwar für Basis-CRUD nutzbar, aber nicht als vollständige Control-Plane für Betrieb, Wartung, Addon-Lifecycle und YForm-Datenmanagement.