一貫した設計原則なしにAPIを構築すると、混乱を招くインターフェースと貧弱な開発者体験につながります。このスキルは、保守可能で文書化されたAPIを作成するための実証済みのRESTおよびGraphQLパターンを提供し、ニーズに合わせてスケールできるようにします。
下载技能 ZIP
在 Claude 中上传
前往 设置 → 功能 → 技能 → 上传技能
开启并开始使用
测试它
正在使用“api-design-principles”。 eコマース商品カタログのエンドポイントを設計
预期结果:
- GET /api/v1/products - 商品をページネーション付きで一覧表示
- GET /api/v1/products/{id} - 商品詳細を取得
- POST /api/v1/products - 商品を作成（管理者のみ）
- PUT /api/v1/products/{id} - 商品を置換（管理者のみ）
- PATCH /api/v1/products/{id} - 商品フィールドを更新（管理者のみ）
- DELETE /api/v1/products/{id} - 商品を削除（管理者のみ）
- GET /api/v1/products/{id}/reviews - 商品レビューを一覧表示
- GET /api/v1/categories/{id}/products - カテゴリ別商品を一覧表示
正在使用“api-design-principles”。 一般的なシナリオのHTTPステータスコードは？
预期结果:
- 200 OK - 成功したGET、PUT、PATCHリクエスト
- 201 Created - リソース作成に成功したPOST
- 204 No Content - 成功したDELETEまたは空のレスポンス
- 400 Bad Request - 不正なJSONまたは無効な構文
- 401 Unauthorized - 認証の欠如または有効期限切れ
- 403 Forbidden - 有効な認証だが不十分な権限
- 404 Not Found - リソースが存在しない
- 409 Conflict - リソースの競合（例：重複キー）
- 422 Unprocessable Entity - 検証エラー
- 429 Too Many Requests - レート制限超過
- 500 Internal Server Error - 予期しないサーバー障害
安全审计
安全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.
质量评分
你能构建什么
グリーンフィールドAPI設計
実装を開始する前に、適切なリソースモデリング、エンドポイント構造、ドキュメント標準を使用して、新しいRESTまたはGraphQL APIをゼロから設計します。
APIレビューとリファクタリング
設計原則に対して既存のAPIエンドポイントを評価し、不一致を特定して命名規則を改善し、移行戦略を計画します。
チーム標準ドキュメント
チームの整合性のために、バージョニング、エラーハンドリング、認証パターン、レスポンス形式をカバーする組織全体のAPI設計ガイドラインを確立します。
试试这些提示
著者、投稿、コメントを持つブログシステムのRESTエンドポイントを設計する必要があります。RESTのベストプラクティスに従って、URL階層、HTTPメソッド、レスポンス形式の構造を支援してください。
ユーザー管理システム用のGraphQLスキーマをレビューしてください。null非許容型の適切な使用とインターフェース実装を確認し、クエリ効率の改善とN+1問題の回避を提案してください。
APIに破壊的な変更が予定されています。ユースケースに対して、URLパスバージョニング、ヘッダーバージョニング、クエリパラメータアプローチを比較してください。非推奨化タイムラインの推奨事項を含めてください。
REST API用の一貫したエラーレスポンス形式を設計してください。フィールドレベルの検証エラー、プログラム的な処理用のエラーコード、一般的なシナリオ用の適切なHTTPステータスコードを含めてください。
最佳实践
- リソースコレクションには複数形の名詞を使用し、URL階層を浅く保つ（最大2〜3レベルのネスト）
- ドキュメント化されたページサイズ制限を持つ一貫したページネーションを実装し、レスポンスに総数メタデータを含める
- URLパスまたはヘッダーバージョニングを使用して最初からAPIをバージョニングし、古いバージョンの明確な非推奨ポリシーを維持する
避免
- リソース名詞での適切なHTTPメソッドの代わりに、/createUserや/getUserByIdなどのエンドポイントで動詞を使用する
- クライアントの期待を裏切る類似のエンドポイント間で異なるレスポンス形式またはフィールド名を返す
- リソースを過度に結合する/users/{id}/orders/{orderId}/items/{itemId}/reviewsのような深くネストされたURL