api-design

Topics in the source

• API デザイン パターン
• アクティブ化するとき
• リソース デザイン
• URL 構造
• 命名規則
• HTTP メソッドとステータス コード
• メソッド セマンティクス
• ステータス コード リファレンス

一貫性のある開発者フレンドリーな REST API を設計するための規約とベスト プラクティス。 新しい API エンドポイントを設計しているとき 既存の API 契約をレビューしているとき ページネーション、フィルタリング、またはソートを追加しているとき API のエラー処理を実装しているとき API バージョン管理戦略を計画しているとき パブリックまたはパートナー向けの API を構築しているとき | メソッド | べき等 | セーフ | 使用対象 | |--------|--------|--------|---------| | GET | はい | はい | リソースを取得 | | POST | いいえ | いいえ | リソースを作成、アクションをトリガー | | PUT | はい | いいえ | リソースの完全な置換 | | PATCH | いいえ | いいえ | リソースの部分的な更新 | | DELETE | はい | いいえ | リソースを削除 | PATCH は適切な実装でべき等にすることができます 長所: 実装が簡単、「N ページにジャンプ」をサポート 短所: 大きなオフセット（OFFSET 100000）で低速、同時挿入で矛盾 長所: 位置に関わらず一貫性のあるパフォーマンス、同時挿入では安定 短所: 任意のページへのジャンプができない、カーソルが不透明 | ユースケース | ページネーション タイプ | |----------|----------------| | 管理ダッシュボード、小さなデータセット（<10K） | オフセット | | 無限スクロール、フィード、大きなデータセット | カーソル | | パブリック API | カーソル（デフォルト）とオフセット（オプション） | | 検索結果 | オフセット（ユーザーはページ番号を期待） | | ティア | 制限 | ウィンドウ | ユースケース | |-----|-------|--------|----------| | 匿名 | 30/分 | IP あたり | パブリック エンドポイント | | 認証済み | 100/分 | ユーザーあたり | 標準 API アクセス | | プレミアム | 1000/分 | API キーあたり | 有料 API プラン | | 内部 | 10000/分 | サービスあたり | サービス間通信 | 長所: 明示的、ルーティングが簡単、キャッシャブル 短所: バージョン間で URL が変更される 長所: クリーンな URL 短所: テストが困難、忘れやすい 新しいエンドポイントを本番環境に配信する前に： [ ] リソース URL は命名規則に従う（複数形、ケバブケース、動詞なし） [ ] 正しい HTTP メソッドが使用されている（読み取り

This is an excerpt. Refer to the complete source and its current requirements.