概要

• RESTは Roy Fieldingの論文 で提唱された アーキテクチャスタイル
• RESTの本質は スケーラビリティ・シンプルさ・適応性 の追求
• HATEOAS（ハイパーメディア駆動） がRESTの重要な原則
• リソースは URIで一意に識別される抽象概念
• RESTful APIと呼ぶには 厳格なルールと制約 が存在

RESTの本質とFielding論文の要点

• RESTは “Representational State Transfer” の略称、 ネットワーク型システム設計 のためのスタイル
• “Architectural Styles and the Design of Network-based Software Architectures” （2000年、Roy T. Fielding著）で初めて体系化
• RESTは スケーラビリティ、パフォーマンス、保守性 を重視した設計指針
• Webサービス設計 における 分散システムの成功要因 としてREST原則を紹介
• RESTは HTTPメソッドやCRUD に限定されず、 原則と制約 の集合体

RESTの誤解と正しい理解

• REST=CRUD や RESTful APIは動詞禁止 などの俗説は誤り

• RESTの本質は ハイパーメディア（HATEOAS） による状態遷移の駆動

• “REST APIs must be hypertext-driven.” （Fielding, 2008年）という明確な主張

• ハイパーメディア制御 は、リソース表現内に次のアクションを案内するリンクや操作情報を埋め込む仕組み

• クライアントとサーバーの 疎結合 ・ 進化可能性 の確保が目的

  • 例：

    {
      "orderId": 123,
      "_links": {
        "self": { "href": "/orders/123" },
        "cancel": { "href": "/orders/123/cancel", "method": "POST" }
      }
    }
    

RESTにおける「リソース」とは

• RESTにおけるリソースは URIで識別可能なあらゆる情報単位
• 物理オブジェクト、概念、ドキュメント、サービス、抽象的なもの までも含む
• リソースは サーバー上のエンティティそのものではなく、抽象的なマッピング
• RFC 3986 も「リソースはURIで識別できるすべてのもの」と定義
• 例：電子文書、画像、サービス、人物、企業、数値、関係タイプなど

FieldingによるRESTful APIの条件

• HTTPベースなら何でもREST API という誤解をFielding自身が批判

• RESTful APIと呼ぶための 6つのルール を提示

  1. 単一プロトコル依存の排除
     • URIによる識別は HTTP固有でなく、URI全般 で成り立つべき
  2. プロトコルの拡張・改変の禁止
     • HTTP標準の範囲内で動作、 独自拡張や仕様破壊は禁止
  3. URI設計よりメディアタイプ重視
     • リソース表現のフォーマットやリンク設計 に注力
     • URIやエンドポイントの構造記述は最小限に
  4. 固定リソース名・階層の否定
     • クライアントがURI構造を前提にしない設計
     • URI生成方法をサーバーが表現内で動的に指示
  5. 型付きリソースの排除
     • クライアントにとって重要なのは 表現のメディアタイプと標準化された関係名 のみ
  6. 初期URI以外の事前知識不要
     • 初期URIと標準メディアタイプ のみで利用開始
     • 以降の状態遷移はすべて サーバー提供のリンクや操作 によって誘導

REST設計ルールの解釈

• 1. プロトコル依存の排除

  • URIは 資源の識別 と アクセス手段 を分離
  • URLはURIの一種 であり、API設計は HTTP固有に依存しない べき

• 2. プロトコル変更の禁止

  • HTTP標準の厳守
  • 標準の曖昧部分は明確化してもよいが、 新たな意味付けや破壊的変更は禁止

• 3. URIよりメディアタイプ設計

  • APIは データ表現形式（例：JSON, HTML）とリンク設計 に注力

  • URIの構造や操作のドキュメント化 よりも、 表現内のリンクや操作情報 の設計が重要

    • 例：

      {
        "name": "John Doe",
        "status": "inactive",
        "_links": { ... }
      }
      

• 4. 固定リソース名・階層の否定

  • サーバー主導のURI生成 （HTMLフォームやURIテンプレートなど）

• 5. 型付きリソースの排除

  • クライアントは 表現のメディアタイプとリンク関係名 のみを認識

• 6. 初期URI以外の事前知識不要

  • 初期エントリーポイントURIと標準メディアタイプ だけで利用開始
  • 以降の状態遷移は サーバーからのリンク・操作案内 に従う

---

REST設計のまとめ

• RESTは 単なるHTTP API設計手法ではなく、厳密なアーキテクチャスタイル
• HATEOAS の実装がRESTful APIの鍵
• URIで識別できるものはすべてリソース
• メディアタイプ設計とハイパーメディア制御 に注力
• 「RESTful API」と呼ぶには厳格な条件 があることを理解する必要