Ceeds Academy教材アプリ教材・症状語・タグで検索
索引グラフ試す
設計▸API設計

API設計: REST の基礎(リソース・メソッド・ステータス・契約)

knowledge所要 25分最新草稿
前提: 設計: 基礎(関心の分離・責務・凝集と結合)
意味グラフ(この教材と内容的に近い教材・1ネスト)
例え(Analogies)
API設計=メニューと注文ルール

メニュー(リソース)と注文方法(メソッド)、できあがり/品切れ(ステータス)を、誰が来ても同じ作法で扱えるよう決めた約束。動詞で頼む(/getUser)より、料理名+頼み方が綣麗。

概要

📍 設計 ▸ API設計 ▸ REST | 種別: knowledge | facts_as_of 2026-06

公式ドキュメント — knowledge

🎞 スライド

REST=「リソース+メソッド」

URLは名詞、操作はHTTPメソッド

リソースとメソッド(テキスト図)

[クライアント] ──GET /users/1──▶ [サーバ] 取得
──POST /users ──▶ 作成
──PUT /users/1──▶ 置換(べき等)
──DELETE /users/1──▶ 削除(べき等)
◀──ステータス(2xx/4xx/5xx)──

契約=入出力スキーマを明示

Pydantic / OpenAPI で型を固定 → クライアントと約束

—
クリックで一覧(遷移しない)
出典(sources)

REST/HTTP 一般 ; 2026-06確認

確認問題(Review-Questions)
PUT/DELETEに期待される性質は?択一
応用公式
解答・解説▾ 開く

べき等性(何度実行しても同じ結果)。

RESTでURLに動詞を入れないのはなぜ?記述
基礎公式
解答・解説▾ 開く

リソース(名詞)をURLで表し、操作はHTTPメソッドで表すから。

目次
例え概要公式ドキュメント出典確認問題
鮮度
最新
更新: 2026-06-15
次回棚卸し: 2028-06-15
周期: 24か月
版: REST/API設計一般

概要

API設計はクライアントとの契約。REST はリソース(名詞)を URL で表し、HTTPメソッドで操作する。適切なステータスと入出力スキーマで約束を明示する。

公式ドキュメント準拠

  • リソース指向:/users/1(名詞)。操作はメソッド:GET/POST/PUT/DELETE。
  • ステータスを適切に(2xx/4xx/5xx)。契約:入出力スキーマを明示(Pydantic/OpenAPI)。
  • べき等性(PUT/DELETEは何度でも同結果)・バージョニング。FastAPI+Pydanticで実装。

出典: REST/HTTP 一般 / OpenAPI。

🧭 誤解訂正集

よくある誤解 正しい理解
URLに動詞(/getUser) リソース(名詞)+メソッド
全部200で返す 適切なステータスを使う

📖 用語

  • REST … リソースをURLで表し、HTTPメソッドで操作する設計スタイル。
  • リソース … APIが扱う対象(名詞・例 /users/1)。
  • HTTPメソッド … GET/POST/PUT/DELETE 等の操作種別。
  • ステータスコード … 結果区分(2xx成功 / 4xx要求側エラー / 5xxサーバ側エラー)。
  • 契約 / スキーマ … 入出力の型の約束(Pydantic/OpenAPI で明示)。
  • べき等性 … 同じ操作を何度実行しても結果が変わらない性質(PUT/DELETE)。

✅ 確認の目安(can-do)

リソース・メソッド・ステータス・契約を区別し、**「このエンドポイントはどのメソッド・どのステータス・どんなスキーマか」**を判断できる。