Eine gute API fühlt sich auf die beste Art langweilig an: vorhersehbare URLs, ehrliche Fehler, kleine stabile Schemata, keine Überraschungen. Das sind die Prinzipien, die die Noxyr Server API prägen. Sie sind von den Industriestandards übernommen, die hinter Stripe, Resend, OpenAI und der offiziellen Discord-API stehen.
1. Versionierte URLs
Jeder Endpunkt liegt unter /api/v1/. Wenn wir inkompatible Änderungen einführen, landen sie unter /api/v2/: Alte Integrationen funktionieren weiter. Discord macht dasselbe mit /api/v10/. Wenn deine API nicht versioniert ist, wird jede Schema-Änderung zu einer Supportanfrage.
2. Erst Ressourcen, dann Aktionen
Noxyr-Endpunkte sind nach Substantiven benannt: server, tickets, activity, invoices, reviews, giveaways. Alle nur lesend, alle GET. Wenn wir Schreibzugriffe hinzufügen, sind es POST/PATCH/DELETE auf denselben Ressourcen. Das passt sauber zu REST-Konventionen und hält das Denkmodell schlank.
3. Bearer-Tokens, ein Geheimnis
Die Authentifizierung läuft über Authorization: Bearer nxr_.... Keine signierten Anfragen, kein OAuth-Ablauf für rein lesende Serverdaten. Moderne APIs für Entwickler setzen zunehmend darauf, weil es überall funktioniert: curl, Browser, Postman, Serverless-Edges. Discord verwendet Bearer-Tokens auch für per OAuth autorisierte Nutzer; das Muster ist universell.
4. Nur Hashes speichern
Jeder Noxyr-Schlüssel wird serverseitig mit SHA-256 gehasht. Der Rohwert wird bei der Erstellung einmal angezeigt und danach nie wieder. Würde unsere Datenbank geleakt, wäre kein Schlüssel nutzbar. Stripe, GitHub, Resend und jeder andere gut geführte API-Anbieter machen das so; umkehrbare Schlüsselspeicherung ist ein klares Warnsignal.
5. Feingranulare Berechtigungen
Ein Schlüssel, sechs unabhängige Schalter. Bewertungen sind öffentliche Daten, Umsätze sind privat. Wenn du sie trennst, kannst du einem Marketing-Partner einen Schlüssel nur für Bewertungen geben und die Umsatzzahlen hinter einem anderen Schalter lassen. Änderungen an Berechtigungen wirken sofort (sie werden bei jeder Anfrage geprüft), sodass ein Widerruf keine Schlüsselrotation braucht.
6. Ehrliche Fehlerantworten
Jeder Fehler ist JSON mit einem stabilen maschinenlesbaren Code und einer menschenlesbaren Nachricht:
{ "error": "scope_disabled", "message": "The \"tickets\" scope is turned off for this key. Enable it on the dashboard API page." }Maschinenlesbare Codes machen Wiederholungen und Dashboards einfach. Menschenlesbare Nachrichten machen das Debuggen schnell. Die Suchanfragen nach „discord increased api errors“ im Juli 2026 (Google Trends: „Breakout“) zeigen, was passiert, wenn Fehler undurchsichtig sind: Nutzer fangen an zu raten.
7. Lückenlose Zeitreihen
Der Endpunkt /api/v1/activity liefert jeden Tag des angefragten Zeitraums zurück, auch wenn die Anzahl null ist. Frontends müssen Lücken nicht selbst füllen, und Diagramme springen nicht zwischen weit auseinanderliegenden Daten. Das ist eine kleine Annehmlichkeit mit einem großen Gewinn an Komfort.
8. Rate-Limits mit Headern
Jede Antwort enthält RateLimit-*-Header, damit Clients zurückschalten können, bevor sie ein 429 bekommen. Das ist das standardisierte IETF-Draft-Format, dieselbe Struktur wie bei GitHub und anderen modernen APIs. Daher funktioniert jede vorhandene Client-Bibliothek, die es spricht, direkt.
9. Großzügiges CORS für rein lesende Daten
Rein lesende Endpunkte senden Access-Control-Allow-Origin: *. Da der Schlüssel authentifiziert und nicht der Ursprung, kostet das Öffnen von CORS sicherheitstechnisch nichts und erlaubt Browser-Tools, die API direkt aufzurufen, ohne Proxy-Gerüst und ohne Localhost-Umweg.
10. Kleine, stabile Schemata
Jede Antwort passt auf einen Bildschirm. Keine optionalen verschachtelten Objekte, keine Felder, die nur erscheinen, wenn ein Feature-Flag aktiv ist. Kleine Schemata lassen sich cachen, testen und in TypeScript leicht typisieren.
In der Praxis siehst du es hier: Server-API-Tutorial. Und wenn Discord selbst Probleme macht: Was diese Discord-API-Fehler tatsächlich bedeuten.