일관된 설계 원칙 없이 API를 구축하면 혼란스러운 인터페이스와 낮은 개발자 경험으로 이어집니다. 이 스킬은 검증된 REST 및 GraphQL 패턴을 제공하여 유지 관리가 쉽고 잘 문서화된 API를 만들 수 있게 해줍니다.
Télécharger le ZIP du skill
Importer dans Claude
Allez dans Paramètres → Capacités → Skills → Importer un skill
Activez et commencez à utiliser
Tester
Utilisation de "api-design-principles". Design endpoints for an e-commerce product catalog
Résultat attendu:
- GET /api/v1/products - List products with pagination
- GET /api/v1/products/{id} - Get product details
- POST /api/v1/products - Create product (admin only)
- PUT /api/v1/products/{id} - Replace product (admin only)
- PATCH /api/v1/products/{id} - Update product fields (admin only)
- DELETE /api/v1/products/{id} - Remove product (admin only)
- GET /api/v1/products/{id}/reviews - List product reviews
- GET /api/v1/categories/{id}/products - List products by category
Utilisation de "api-design-principles". What HTTP status codes for common scenarios?
Résultat attendu:
- 200 OK - Successful GET, PUT, PATCH requests
- 201 Created - Successful POST with resource creation
- 204 No Content - Successful DELETE or empty response
- 400 Bad Request - Malformed JSON or invalid syntax
- 401 Unauthorized - Missing or expired authentication
- 403 Forbidden - Valid auth but insufficient permissions
- 404 Not Found - Resource does not exist
- 409 Conflict - Resource conflict (e.g., duplicate key)
- 422 Unprocessable Entity - Validation errors
- 429 Too Many Requests - Rate limit exceeded
- 500 Internal Server Error - Unexpected server failure
Audit de sécurité
SûrStatic 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.
Score de qualité
Ce que vous pouvez construire
Greenfield API 설계
구현이 시작되기 전에 적절한 리소스 모델링, 엔드포인트 구조 및 문서화 표준을 사용하여 새로운 REST 또는 GraphQL API를 처음부터 설계하세요.
API 검토 및 리팩토링
설계 원칙에 대해 기존 API 엔드포인트를 평가하여 불일치를 식별하고, 명명 규칙을 개선하며, 마이그레이션 전략을 계획하세요.
팀 표준 문서화
팀 정렬을 위해 버전 관리, 오류 처리, 인증 패턴 및 응답 형식을 포함하는 조직 전체의 API 설계 가이드라인을 수립하세요.
Essayez ces prompts
I need to design REST endpoints for a blog system with authors, posts, and comments. Help me structure the URL hierarchy, HTTP methods, and response formats following REST best practices.
Review my GraphQL schema for a user management system. Check for proper use of non-null types, interface implementations, and suggest improvements for query efficiency and avoid N+1 problems.
My API has breaking changes coming. Compare URL path versioning, header versioning, and query parameter approaches for my use case. Include deprecation timeline recommendations.
Design a consistent error response format for my REST API. Include field-level validation errors, error codes for programmatic handling, and appropriate HTTP status codes for common scenarios.
Bonnes pratiques
- 리소스 컬렉션에는 복수 명사를 사용하고 URL 계층 구조를 얕게 유지하세요 (최대 2-3단계 중첩)
- 문서화된 페이지 크기 제한과 함께 일관된 페이지네이션을 구현하고 응답에 전체 수량 메타데이터를 포함하세요
- URL 경로 또는 헤더 버전 관리를 사용하여 시작부터 API를 버전 관리하고 이전 버전에 대한 명확한 폐기 정책을 유지하세요
Éviter
- 리소스 명사에 대한 적절한 HTTP 메서드 대신 /createUser 또는 /getUserById과 같은 엔드포인트에서 동사 사용
- 유사한 ���드포인트에서 다른 응답 형식 또는 필드 이름을 반환하여 클라이언트 기대치 위반
- 리소스를 너무 긴밀하게 결합하는 /users/{id}/orders/{orderId}/items/{itemId}/reviews와 같은 깊게 중첩된 URL