designing-apis
RESTやGraphQLといったAPIを設計し、エンドポイント定義、エラー処理、バージョン管理、ドキュメント作成まで行い、API開発やレビューに関する質問にも対応できるSkill。
📜 元の英語説明(参考)
Designs REST and GraphQL APIs including endpoints, error handling, versioning, and documentation. Use when creating new APIs, designing endpoints, reviewing API contracts, or when asked about REST, GraphQL, or API patterns.
🇯🇵 日本人クリエイター向け解説
RESTやGraphQLといったAPIを設計し、エンドポイント定義、エラー処理、バージョン管理、ドキュメント作成まで行い、API開発やレビューに関する質問にも対応できるSkill。
※ jpskill.com 編集部が日本のビジネス現場向けに補足した解説です。Skill本体の挙動とは独立した参考情報です。
下記のコマンドをコピーしてターミナル(Mac/Linux)または PowerShell(Windows)に貼り付けてください。 ダウンロード → 解凍 → 配置まで全自動。
mkdir -p ~/.claude/skills && cd ~/.claude/skills && curl -L -o designing-apis.zip https://jpskill.com/download/17942.zip && unzip -o designing-apis.zip && rm designing-apis.zip
$d = "$env:USERPROFILE\.claude\skills"; ni -Force -ItemType Directory $d | Out-Null; iwr https://jpskill.com/download/17942.zip -OutFile "$d\designing-apis.zip"; Expand-Archive "$d\designing-apis.zip" -DestinationPath $d -Force; ri "$d\designing-apis.zip"
完了後、Claude Code を再起動 → 普通に「動画プロンプト作って」のように話しかけるだけで自動発動します。
💾 手動でダウンロードしたい(コマンドが難しい人向け)
- 1. 下の青いボタンを押して
designing-apis.zipをダウンロード - 2. ZIPファイルをダブルクリックで解凍 →
designing-apisフォルダができる - 3. そのフォルダを
C:\Users\あなたの名前\.claude\skills\(Win)または~/.claude/skills/(Mac)へ移動 - 4. Claude Code を再起動
⚠️ ダウンロード・利用は自己責任でお願いします。当サイトは内容・動作・安全性について責任を負いません。
🎯 このSkillでできること
下記の説明文を読むと、このSkillがあなたに何をしてくれるかが分かります。Claudeにこの分野の依頼をすると、自動で発動します。
📦 インストール方法 (3ステップ)
- 1. 上の「ダウンロード」ボタンを押して .skill ファイルを取得
- 2. ファイル名の拡張子を .skill から .zip に変えて展開(macは自動展開可)
- 3. 展開してできたフォルダを、ホームフォルダの
.claude/skills/に置く- · macOS / Linux:
~/.claude/skills/ - · Windows:
%USERPROFILE%\.claude\skills\
- · macOS / Linux:
Claude Code を再起動すれば完了。「このSkillを使って…」と話しかけなくても、関連する依頼で自動的に呼び出されます。
詳しい使い方ガイドを見る →- 最終更新
- 2026-05-18
- 取得日時
- 2026-05-18
- 同梱ファイル
- 1
📖 Skill本文(日本語訳)
※ 原文(英語/中国語)を Gemini で日本語化したものです。Claude 自身は原文を読みます。誤訳がある場合は原文をご確認ください。
API設計
API設計ワークフロー
このチェックリストをコピーして、進捗状況を追跡してください。
API Design Progress:
- [ ] Step 1: リソースと関係性の定義
- [ ] Step 2: エンドポイント構造の設計
- [ ] Step 3: リクエスト/レスポンス形式の定義
- [ ] Step 4: エラー処理の計画
- [ ] Step 5: 認証/認可の追加
- [ ] Step 6: OpenAPI spec によるドキュメント化
- [ ] Step 7: チェックリストに対する設計の検証
REST API設計
URL構造
# リソースベースのURL(動詞ではなく名詞)
GET /users # ユーザー一覧
GET /users/:id # ユーザー取得
POST /users # ユーザー作成
PUT /users/:id # ユーザー置換
PATCH /users/:id # ユーザー更新
DELETE /users/:id # ユーザー削除
# ネストされたリソース
GET /users/:id/orders # ユーザーの注文
POST /users/:id/orders # ユーザーの注文作成
# フィルタリング/ページネーションのためのクエリパラメータ
GET /users?role=admin&status=active
GET /users?page=2&limit=20&sort=-createdAt
HTTPステータスコード
| Code | Meaning | Use Case |
|---|---|---|
| 200 | OK | GET、PUT、PATCH の成功 |
| 201 | Created | POST の成功 |
| 204 | No Content | DELETE の成功 |
| 400 | Bad Request | 無効な入力 |
| 401 | Unauthorized | 認証情報の欠落/無効 |
| 403 | Forbidden | 有効な認証情報、権限なし |
| 404 | Not Found | リソースが存在しない |
| 409 | Conflict | 重複、状態の競合 |
| 422 | Unprocessable | バリデーション失敗 |
| 429 | Too Many Requests | レート制限 |
| 500 | Internal Error | サーバーエラー |
レスポンス形式
成功レスポンス:
{
"data": {
"id": "123",
"type": "user",
"attributes": {
"name": "John Doe",
"email": "john@example.com"
}
},
"meta": {
"requestId": "abc-123"
}
}
ページネーション付きリストレスポンス:
{
"data": [...],
"meta": {
"total": 100,
"page": 1,
"limit": 20,
"totalPages": 5
},
"links": {
"self": "/users?page=1",
"next": "/users?page=2",
"last": "/users?page=5"
}
}
エラーレスポンス:
{
"error": {
"code": "VALIDATION_ERROR",
"message": "Invalid input data",
"details": [
{
"field": "email",
"message": "Must be a valid email address"
}
]
},
"meta": {
"requestId": "abc-123"
}
}
APIバージョニング
URLバージョニング(推奨):
/api/v1/users
/api/v2/users
ヘッダーバージョニング:
Accept: application/vnd.api+json; version=1
認証パターン
JWT Bearer Token:
Authorization: Bearer eyJhbGciOiJIUzI1NiIs...
API Key:
X-API-Key: your-api-key
レート制限ヘッダー
X-RateLimit-Limit: 100
X-RateLimit-Remaining: 95
X-RateLimit-Reset: 1609459200
Retry-After: 60
GraphQLパターン
スキーマ設計:
type Query {
user(id: ID!): User
users(filter: UserFilter, pagination: Pagination): UserConnection!
}
type Mutation {
createUser(input: CreateUserInput!): UserPayload!
updateUser(id: ID!, input: UpdateUserInput!): UserPayload!
}
type User {
id: ID!
name: String!
email: String!
orders(first: Int, after: String): OrderConnection!
}
input CreateUserInput {
name: String!
email: String!
}
type UserPayload {
user: User
errors: [Error!]
}
OpenAPI仕様テンプレート
完全な OpenAPI 3.0 仕様テンプレートについては、OPENAPI-TEMPLATE.md を参照してください。
API設計の検証
設計完了後、このチェックリストに対して検証してください。
Validation Checklist:
- [ ] すべてのエンドポイントで動詞ではなく名詞を使用している
- [ ] HTTPメソッドが操作と正しく一致している
- [ ] エンドポイント間で一貫したレスポンス形式である
- [ ] エラーレスポンスには、実行可能な詳細が含まれている
- [ ] リストエンドポイントにページネーションが実装されている
- [ ] 保護されたエンドポイントに対して認証が定義されている
- [ ] レート制限ヘッダーがドキュメント化されている
- [ ] OpenAPI spec が完全で有効である
検証に失敗した場合は、関連する設計ステップに戻り、問題を解決してください。
セキュリティチェックリスト
- [ ] HTTPS のみ
- [ ] すべてのエンドポイントでの認証
- [ ] 認可チェック
- [ ] 入力検証
- [ ] レート制限
- [ ] リクエストサイズ制限
- [ ] CORS が適切に設定されている
- [ ] URL に機密データを含めない
- [ ] 監査ログ
📜 原文 SKILL.md(Claudeが読む英語/中国語)を展開
Designing APIs
API Design Workflow
Copy this checklist and track progress:
API Design Progress:
- [ ] Step 1: Define resources and relationships
- [ ] Step 2: Design endpoint structure
- [ ] Step 3: Define request/response formats
- [ ] Step 4: Plan error handling
- [ ] Step 5: Add authentication/authorization
- [ ] Step 6: Document with OpenAPI spec
- [ ] Step 7: Validate design against checklist
REST API Design
URL Structure
# Resource-based URLs (nouns, not verbs)
GET /users # List users
GET /users/:id # Get user
POST /users # Create user
PUT /users/:id # Replace user
PATCH /users/:id # Update user
DELETE /users/:id # Delete user
# Nested resources
GET /users/:id/orders # User's orders
POST /users/:id/orders # Create order for user
# Query parameters for filtering/pagination
GET /users?role=admin&status=active
GET /users?page=2&limit=20&sort=-createdAt
HTTP Status Codes
| Code | Meaning | Use Case |
|---|---|---|
| 200 | OK | Successful GET, PUT, PATCH |
| 201 | Created | Successful POST |
| 204 | No Content | Successful DELETE |
| 400 | Bad Request | Invalid input |
| 401 | Unauthorized | Missing/invalid auth |
| 403 | Forbidden | Valid auth, no permission |
| 404 | Not Found | Resource doesn't exist |
| 409 | Conflict | Duplicate, state conflict |
| 422 | Unprocessable | Validation failed |
| 429 | Too Many Requests | Rate limited |
| 500 | Internal Error | Server error |
Response Formats
Success Response:
{
"data": {
"id": "123",
"type": "user",
"attributes": {
"name": "John Doe",
"email": "john@example.com"
}
},
"meta": {
"requestId": "abc-123"
}
}
List Response with Pagination:
{
"data": [...],
"meta": {
"total": 100,
"page": 1,
"limit": 20,
"totalPages": 5
},
"links": {
"self": "/users?page=1",
"next": "/users?page=2",
"last": "/users?page=5"
}
}
Error Response:
{
"error": {
"code": "VALIDATION_ERROR",
"message": "Invalid input data",
"details": [
{
"field": "email",
"message": "Must be a valid email address"
}
]
},
"meta": {
"requestId": "abc-123"
}
}
API Versioning
URL Versioning (Recommended):
/api/v1/users
/api/v2/users
Header Versioning:
Accept: application/vnd.api+json; version=1
Authentication Patterns
JWT Bearer Token:
Authorization: Bearer eyJhbGciOiJIUzI1NiIs...
API Key:
X-API-Key: your-api-key
Rate Limiting Headers
X-RateLimit-Limit: 100
X-RateLimit-Remaining: 95
X-RateLimit-Reset: 1609459200
Retry-After: 60
GraphQL Patterns
Schema Design:
type Query {
user(id: ID!): User
users(filter: UserFilter, pagination: Pagination): UserConnection!
}
type Mutation {
createUser(input: CreateUserInput!): UserPayload!
updateUser(id: ID!, input: UpdateUserInput!): UserPayload!
}
type User {
id: ID!
name: String!
email: String!
orders(first: Int, after: String): OrderConnection!
}
input CreateUserInput {
name: String!
email: String!
}
type UserPayload {
user: User
errors: [Error!]
}
OpenAPI Specification Template
See OPENAPI-TEMPLATE.md for the full OpenAPI 3.0 specification template.
API Design Validation
After completing the design, validate against this checklist:
Validation Checklist:
- [ ] All endpoints use nouns, not verbs
- [ ] HTTP methods match operations correctly
- [ ] Consistent response format across endpoints
- [ ] Error responses include actionable details
- [ ] Pagination implemented for list endpoints
- [ ] Authentication defined for protected endpoints
- [ ] Rate limiting headers documented
- [ ] OpenAPI spec is complete and valid
If validation fails, return to the relevant design step and address the issues.
Security Checklist
- [ ] HTTPS only
- [ ] Authentication on all endpoints
- [ ] Authorization checks
- [ ] Input validation
- [ ] Rate limiting
- [ ] Request size limits
- [ ] CORS properly configured
- [ ] No sensitive data in URLs
- [ ] Audit logging