Compétences api-design-principles
📦

api-design-principles

Sûr

Entwerfen Sie intuitive und skalierbare APIs

Également disponible depuis: wshobson

Das Erstellen von APIs ohne konsistente Designprinzipien führt zu verwirrenden Schnittstellen und schlechter Entwicklererfahrung. Diese Fähigkeit bietet bewährte REST- und GraphQL-Muster, um wartungsfreundliche, gut dokumentierte APIs zu schaffen, die mit Ihren Anforderungen skalieren.

Prend en charge: Claude Codex Code(CC)
🥈 78 Argent
1

Télécharger le ZIP du skill

2

Importer dans Claude

Allez dans Paramètres → Capacités → Skills → Importer un skill

3

Activez et commencez à utiliser

Tester

Utilisation de "api-design-principles". Entwerfen Sie Endpunkte für einen E-Commerce-Produktkatalog

Résultat attendu:

  • GET /api/v1/products - Produkte mit Paginierung auflisten
  • GET /api/v1/products/{id} - Produktdetails abrufen
  • POST /api/v1/products - Produkt erstellen (nur Admin)
  • PUT /api/v1/products/{id} - Produkt ersetzen (nur Admin)
  • PATCH /api/v1/products/{id} - Produktfelder aktualisieren (nur Admin)
  • DELETE /api/v1/products/{id} - Produkt entfernen (nur Admin)
  • GET /api/v1/products/{id}/reviews - Produktbewertungen auflisten
  • GET /api/v1/categories/{id}/products - Produkte nach Kategorie auflisten

Utilisation de "api-design-principles". Welche HTTP-Statuscodes für gängige Szenarien?

Résultat attendu:

  • 200 OK - Erfolgreiche GET-, PUT-, PATCH-Anfragen
  • 201 Created - Erfolgreicher POST mit Ressourcenerstellung
  • 204 No Content - Erfolgreicher DELETE oder leere Antwort
  • 400 Bad Request - Falsch formatiertes JSON oder ungültige Syntax
  • 401 Unauthorized - Fehlende oder abgelaufene Authentifizierung
  • 403 Forbidden - Gültige Authentifizierung, aber unzureichende Berechtigungen
  • 404 Not Found - Ressource existiert nicht
  • 409 Conflict - Ressourcenkonflikt (z. B. doppelter Schlüssel)
  • 422 Unprocessable Entity - Validierungsfehler
  • 429 Too Many Requests - Rate-Limit überschritten
  • 500 Internal Server Error - Unerwarteter Serverfehler

Audit de sécurité

Sûr
v1 • 2/24/2026

Static analysis flagged 201 patterns that are all false positives. The skill contains only documentation and educational content about API design. Markdown code blocks (backticks) were incorrectly identified as shell execution. Cryptographic references appear in security checklists, not actual implementations. URL and IP references are documentation examples for API endpoints. No executable code or security risks present.

6
Fichiers analysés
1,886
Lignes analysées
0
résultats
1
Total des audits
Aucun problème de sécurité trouvé
Audité par: claude

Score de qualité

55
Architecture
100
Maintenabilité
87
Contenu
50
Communauté
100
Sécurité
91
Conformité aux spécifications

Ce que vous pouvez construire

Greenfield-API-Design

Entwerfen Sie eine neue REST- oder GraphQL-API von Grund auf mit ordnungsgemäßer Ressourcenmodellierung, Endpunktstruktur und Dokumentationsstandards, bevor die Implementierung beginnt.

API-Überprüfung und Refactoring

Bewerten Sie vorhandene API-Endpunkte anhand von Designprinzipien, um Inkonsistenzen zu identifizieren, Namenskonventionen zu verbessern und Migrationsstrategien zu planen.

Dokumentation von Teamstandards

Etablieren Sie organisationsweite API-Designrichtlinien, die Versionierung, Fehlerbehandlung, Authentifizierungsmuster und Antwortformate für die Teamabstimmung abdecken.

Essayez ces prompts

Grundlegendes REST-Endpunkt-Design
Ich muss REST-Endpunkte für ein Blog-System mit Autoren, Beiträgen und Kommentaren entwerfen. Helfen Sie mir, die URL-Hierarchie, HTTP-Methoden und Antwortformate nach REST-Best-Practices zu strukturieren.
GraphQL-Schema-Überprüfung
Überprüfen Sie mein GraphQL-Schema für ein Benutzerverwaltungssystem. Prüfen Sie die ordnungsgemäße Verwendung von Non-Null-Typen, Schnittstellenimplementierungen und schlagen Sie Verbesserungen für die Abfrageeffizienz vor, um N+1-Probleme zu vermeiden.
API-Versionierungsstrategie
Meine API steht vor bahnbrechenden Änderungen. Vergleichen Sie URL-Pfad-Versionierung, Header-Versionierung und Query-Parameter-Ansätze für meinen Anwendungsfall. Fügen Sie Empfehlungen für Deprecation-Zeitpläne hinzu.
Fehlerbehandlungsdesign
Entwerfen Sie ein konsistentes Fehlerantwortformat für meine REST-API. Fügen Sie Validierungsfehler auf Feldebene, Fehlercodes für die programmatische Handhabung und geeignete HTTP-Statuscodes für gängige Szenarien hinzu.

Bonnes pratiques

  • Verwenden Sie Plural-Substantive für Ressourcensammlungen und halten Sie URL-Hierarchien flach (maximal 2-3 Ebenen der Verschachtelung)
  • Implementieren Sie konsistente Paginierung mit dokumentierten Seitengrößenlimits und fügen Sie Metadaten zur Gesamtanzahl in Antworten ein
  • Versionieren Sie APIs von Anfang an mithilfe von URL-Pfad- oder Header-Versionierung und pflegen Sie eine klare Deprecation-Richtlinie für ältere Versionen

Éviter

  • Verwendung von Verben in Endpunkten wie /createUser oder /getUserById anstelle von ordnungsgemäßen HTTP-Methoden auf Ressourcen-Substantiven
  • Rückgabe unterschiedlicher Antwortformate oder Feldnamen über ähnliche Endpunkte hinweg, was Client-Erwartungen bricht
  • Tief verschachtelte URLs wie /users/{id}/orders/{orderId}/items/{itemId}/reviews, die Ressourcen zu stark koppeln

Foire aux questions

Sollte ich REST oder GraphQL für meine neue API verwenden?
Wählen Sie REST, wenn Sie klare Ressourcengrenzen haben, starkes Caching benötigen oder einfache CRUD-Operationen bereitstellen. Wählen Sie GraphQL, wenn Clients flexibles Daten-Fetching benötigen, Sie komplexe Beziehungen haben oder mobile Clients Anfragen minimieren müssen.
Wie handhabe ich API-Versionierung, ohne bestehende Clients zu brechen?
Beginnen Sie die Versionierung ab v1 beim Launch. Erstellen Sie bei bahnbrechenden Änderungen v2 parallel zu v1. Dokumentieren Sie Deprecation-Zeitpläne (typischerweise 6-12 Monate). Verwenden Sie Sunset-Header, um Clients über bevorstehende Löschungen zu informieren. Entfernen Sie niemals Versionen ohne ausreichende Vorankündigung.
Welchen Paginierungsansatz sollte ich für große Datensätze verwenden?
Verwenden Sie offset-basierte Paginierung (page/page_size) für einfache Anwendungsfälle mit Datensätzen unter 100.000. Verwenden Sie cursor-basierte Paginierung für große Datensätze oder Echtzeitdaten, bei denen Konsistenz wichtig ist. Erzwingen Sie immer maximale Seitengrößen, um Missbrauch zu verhindern.
Wie entwerfe ich Fehlerantworten, die Entwickler tatsächlich verwenden können?
Fügen Sie einen maschinenlesbaren Fehlercode, eine für Menschen lesbare Nachricht und optionale Feld-details hinzu. Verwenden Sie eine konsistente Struktur über alle Endpunkte hinweg. Dokumentieren Sie alle Fehlercodes in Ihrer API-Referenz. Geben Sie Validierungsfehler als 422 mit feldspezifischen Nachrichten zurück.
Welche Rate-Limiting-Strategie sollte ich implementieren?
Beginnen Sie mit Anfragen pro Minute pro API-Schlüssel oder IP. Fügen Sie Rate-Limit-Header hinzu (X-RateLimit-Limit, X-RateLimit-Remaining, X-RateLimit-Reset). Geben Sie bei Überschreitung den Status 429 mit Retry-After-Header zurück. Berücksichtigen Sie gestaffelte Limits basierend auf Authentifizierungsstufe.
Wie handhabe ich Authentifizierung im API-Design?
Verwenden Sie Bearer-Token (JWT oder undurchsichtig) in Authorization-Headern für die meisten APIs. Erwägen Sie API-Schlüssel für Server-zu-Server-Kommunikation. Akzeptieren Sie niemals Anmeldedaten in URL-Parametern. Dokumentieren Sie Token-Aktualisierungsabläufe klar. Geben Sie 401 für Authentifizierungsfehler, 403 für Autorisierungsfehler zurück.