クイズの説明
Step 1で学んだ内容の理解度をチェックします。
- 全8問
- 合格ライン: 80%（7問正解）
- 不合格の場合は復習してから再挑戦してください
問題
Q1. RESTにおいて、URLに含めるべきなのはどれですか？
- A) 動詞（getUser, createOrder）
- B) 名詞の複数形（users, orders）
- C) 名詞の単数形（user, order）
- D) HTTPメソッド名（get-users, post-order）
答えを見る
正解: B
RESTでは、URLはリソースを表す名詞の複数形で構成します。操作はHTTPメソッド（GET, POST, PUT, DELETE）で表現するため、URLに動詞を含める必要はありません。
例: GET /api/v1/users（ユーザー一覧取得）
Q2. HTTPメソッドの「冪等性」について正しい説明はどれですか？
- A) リクエストが必ず成功する性質
- B) リクエストの処理が高速である性質
- C) 同じリクエストを何度実行しても結果が同じになる性質
- D) リクエストがキャッシュされる性質
答えを見る
正解: C
冪等性（idempotency）とは、同じ操作を複数回実行しても結果が変わらない性質です。
- GET: 冪等（何度取得しても同じデータ）
- PUT: 冪等（何度置換しても同じ結果）
- DELETE: 冪等（既に削除済みなら変化なし）
- POST: 非冪等（実行するたびに新しいリソースが作成される）
Q3. 新しいリソースの作成に成功した場合、最も適切なHTTPステータスコードはどれですか？
- A) 200 OK
- B) 201 Created
- C) 204 No Content
- D) 202 Accepted
答えを見る
正解: B
- 200 OK: 一般的な成功（GETやPUTの成功時に使う）
- 201 Created: リソースの新規作成が成功した場合に使う
- 204 No Content: 成功したが返すデータがない場合（DELETE等）
- 202 Accepted: 非同期処理を受け付けた場合
POSTで新しいリソースを作成した場合は201を返し、Locationヘッダーに新リソースのURIを含めるのがベストプラクティスです。
Q4. APIのURL設計として最も適切なものはどれですか？
- A)
GET /api/v1/users/123/orders/456/items/789/reviews - B)
GET /api/v1/order-items/789/reviews - C)
GET /api/v1/getOrderItemReviews?itemId=789 - D)
GET /api/v1/OrderItems/789/Reviews
答えを見る
正解: B
- A: ネストが深すぎる（3階層以上）
- B: ケバブケース、2階層以内、名詞の複数形で適切
- C: URLに動詞（get）が含まれている
- D: PascalCaseが使われている（URLはケバブケースが推奨）
ネストが深くなる場合は、リソースを直接参照するURIに変更するのがベストプラクティスです。
Q5. ページネーションでカーソルベースが適している場面はどれですか？
- A) 管理画面で任意のページにジャンプしたい場合
- B) SNSのタイムラインのような大規模データを扱う場合
- C) 全件数が100件以下の小規模データの場合
- D) PDFレポートを生成する場合
答えを見る
正解: B
カーソルベースのページネーションは以下の特徴があります：
- データの追加・削除があっても正確にページングできる
- 大規模データでもパフォーマンスが安定する
- ただし、任意のページへのジャンプはできない
SNSのタイムラインのように、リアルタイムでデータが追加される大規模データに適しています。
Q6. APIのエラーレスポンスにおいて、セキュリティ上避けるべきなのはどれですか？
- A) traceId を含める
- B) スタックトレースやSQL文を含める
- C) エラーコードを含める
- D) ユーザー向けメッセージを含める
答えを見る
正解: B
スタックトレース、SQL文、サーバーのファイルパスなどの内部情報をエラーレスポンスに含めると、攻撃者にシステムの構成情報を与えてしまいます。
詳細なエラー情報はサーバーのログに記録し、クライアントにはtraceIdを返して追跡可能にするのがベストプラクティスです。
Q7. RESTのステートレス原則について正しいものはどれですか？
- A) サーバーはクライアントのセッション情報を保持する
- B) 各リクエストは独立しており、必要な情報はすべてリクエストに含める
- C) クライアントはサーバーの状態を管理する
- D) ステートレスとは状態を一切持たないことを意味する
答えを見る
正解: B
RESTのステートレス原則では、サーバーはリクエスト間でクライアントの状態を保持しません。各リクエストには認証情報など、処理に必要な情報がすべて含まれている必要があります。
これにより、どのサーバーでもリクエストを処理できるため、スケーラビリティが向上します。
Q8. 以下のうち、日付・時刻の形式として最も適切なのはどれですか？
- A)
"2025/01/15 09:00:00" - B)
"Jan 15, 2025" - C)
1705305600 - D)
"2025-01-15T09:00:00Z"
答えを見る
正解: D
ISO 8601形式（2025-01-15T09:00:00Z）が最も適切です。
- 国際的に標準化された形式
- タイムゾーン情報を含む（
ZはUTC） - ほぼすべてのプログラミング言語でパースできる
- ソート可能な文字列形式
APIでは日付・時刻をISO 8601で統一するのがベストプラクティスです。
結果
7問以上正解の場合
合格です。おめでとうございます。
Step 1「API設計の世界へようこそ」を完了しました。 次は Step 2「RESTful API設計の深淵」に進みましょう。
6問以下の場合
もう少し復習しましょう。
間違えた問題の内容を、該当するセクションで復習してください：
| 問題 | 復習セクション |
|---|---|
| Q1, Q4 | step1_2 RESTの基本原則 / step1_4 ベストプラクティス |
| Q2, Q3 | step1_2 HTTPメソッド・ステータスコード |
| Q5 | step1_4 ページネーション |
| Q6, Q7 | step1_5 エラーハンドリング / step1_2 ステートレス |
| Q8 | step1_3 良いAPIと悪いAPIの違い |
Step 1 完了
お疲れさまでした。
学んだこと
- APIの基本概念と契約としての性質
- RESTの6つの制約とリソース指向設計
- HTTPメソッドの使い分け（安全性・冪等性）
- 良いAPIと悪いAPIの7つの比較観点
- 命名規則、ページネーション、フィルタリングのベストプラクティス
- RFC 7807に基づくエラーハンドリング設計
次のステップ
Step 2: RESTful API設計の深淵（4時間）
リソース設計の深掘り、HATEOAS、認証・認可、レート制限など、より高度なREST設計を学びます。
推定所要時間: 15分