■ 1. RESTの本来の定義と一般的な誤解
- 一般的にREST APIは「リソース指向のURL設計とHTTPメソッドによるCRUD操作のスタイル」として認識されている
- 本来のRESTは、サーバーのレスポンスに含まれるリンクを辿ってアプリケーション状態を遷移させる、ハイパーメディアを基本とした分散システムの設計原理である
- RESTはAPI設計手法ではなく、HTTPの設計原理を体系化した分散ハイパーメディアシステムの概念である
■ 2. REST論文成立の背景
- 時系列:
- 1996年: Roy T. FieldingがTim Berners-LeeらとHTTP/1.0（RFC 1945）を策定
- 1997〜1999年: FieldingがHTTP/1.1の共著者として設計に深く関与し、プロキシ可能性・キャッシュ可能性を損なうMGET・MHEADの提案を却下
- 2000年: Fieldingがカリフォルニア大学アーバイン校に博士論文「Architectural Styles and the Design of Network-based Software Architectures」を提出
■ 3. Fielding論文の内容
- 論文の動機:
- 新しいAPI設計手法の提案ではなく、HTTP/1.1策定プロセスで採用したアーキテクチャ上の原理を事後的に体系化したもの
- HTTPの設計判断を振り返り、その背後にあった原理を「REST」として定式化した
- 論文の主題:
- 主題はネットワークベースのソフトウェアアーキテクチャスタイルの分類学であり、RESTが直接語られるのは1章のみ
- Pipe-and-Filter、Layered-Client-Server、Client-Cache-Stateless-Serverなどの分類スタイルが並列に論じられ、RESTはこれらの制約を組み合わせた派生スタイルに位置づけられる
- 論文の核心的メッセージ:
- 「一つのアーキテクチャスタイルをすべてに使うな。アプリケーションの要件に合ったスタイルを選べ」
- RESTの適用範囲は「大粒度のハイパーメディアデータ転送」に最適化されており、他の形式には最適ではないと明記されている
- 対象問題領域はWebそのものの構造（組織や国境を越えたドキュメント接続）であり、企業内のバックエンドAPIやモバイルアプリのBFFではない
- 統一インターフェース（Uniform Interface）の4つのサブ制約:
- リソースの識別（Identification of Resources）: すべてのリソースにURIで識別できるアドレスを与える
- 表現を通じたリソースの操作（Manipulation of Resources through Representations）: リソースそのものではなく表現（JSON、HTML等）を介して操作する
- 自己記述的メッセージ（Self-descriptive Messages）: メッセージ自体に処理に必要な情報がすべて含まれる
- HATEOAS: 次に何ができるかはサーバーが返すリンクが示し、クライアントはそのリンクを辿って次のアクションを発見する
■ 4. SOAPの時代とRESTバズワード化の過程
- SOAPの時代（2000年代前半）:
- XMLベースのSOAPが企業間サービス連携の主流であり、WSDL・UDDI・WS-Securityなどの関連仕様が層をなしていた
- 形式性が信頼性の証とみなされていた
- RESTバズワード化（2000年代中頃）:
- SOAPの複雑さへの反動として「HTTPの機能をそのまま使う」アプローチが浮上した
- 2004年、英国オックスフォード大学のMatthew J. DoveyがFielding論文を参照しつつ「REST maps the CRUD operations onto the HTTP verbs」と記述した記事を公開した
- SOAPへのカウンターカルチャーのバズワードとして「REST」という言葉が流通し始めた
- TwoBitHistory（2020年）はこのアプローチをFIOH（Fuck It, Overload HTTP）と呼び、FIOHそのものには問題はないが、FIOHに過ぎないものに「REST」という学術的名称が被せられたことが問題だと指摘した
■ 5. DHHとRailsによる普及
- 2007年のRails 2.0リリースでSOAPサポート（ActionWebService）がデフォルトから廃止され、RESTfulルーティングがフレームワークの中心的な規約として導入された
- DHHの判断は無知に基づくものではなく、Fielding論文を理解し、Fielding本人と直接対話し、HATEOASを試みた上で「自分には要らない」と判断した意図的な選択であった
- 2012年のブログでDHHは導入動機を「知的純粋性のためではない」と述べ、HATEOASを「completely overblown（完全に過大評価）」と断じた
- 「REST」の名を選んだ背景には、アンチSOAPの旗印としてのマーケティング的意味と権威づけの意味があったと筆者は考察している
■ 6. Fielding本人の反応と「RESTish API」の誕生
- 2008年、FieldingはブログにてあらゆるHTTPベースのインターフェースをREST APIと呼ぶ状況に対するフラストレーションを公表した
- 今日「RESTful API」と呼ばれているもの（RESTish、すなわち「なんちゃってREST」）の規則群:
- URL設計: リソースを名詞で表現し、階層構造をパスで表す
- HTTPメソッドのCRUDマッピング: GET（取得）、POST（作成）、PUT（全体更新）、PATCH（部分更新）、DELETE（削除）
- ステータスコードでビジネスロジックの結果を表現する
- データ形式はJSON
- OpenAPI等の外部ドキュメントでエンドポイント仕様を共有する
- この規則群はFieldingが定義した統一インターフェースの4つの制約とは異なるものである
■ 7. リチャードソン成熟度モデルとベストプラクティス化
- 普及の経路:
- 2007年: O'ReillyからREST名を冠した初の本格書籍「RESTful Web Services」（Richardson、Ruby著）がCRUD-over-HTTPスタイルを体系的に解説
- 2008年: Richardson Maturity ModelがQConで発表され、2010年にMartin Fowlerが記事化して広く知られるようになった
- 2012年: Apigeeが「Web API Design」eBookを公開し、「pragmatic REST」を提唱、Fieldingの論文に忠実な立場を「RESTifarian（REST原理主義者）」と呼んだ
- 2016年: GoogleがApigeeを買収し、体系化に権威が加わった
- リチャードソン成熟度モデルの構造:
- Level 0: HTTPを単なるトランスポートとして使用
- Level 1: 個別のリソースにURIを割り当てる
- Level 2: HTTPメソッドを使い分ける（実質的に「RESTful」と称される水準）
- Level 3: HATEOAS（最上位の「到達すれば理想的」なオプション扱い）
- FieldingがRESTの必須要件と位置づけたHATEOASが、このモデルではオプションに格下げされている
- 2013年のO'Reilly書籍「RESTful Web APIs」はハイパーメディアを中心に据え直した「前著の完全な置き換え」を意図したが、誤用はすでに定着していた
■ 8. 修正が機能しなかった構造的理由
- 誤用への指摘は繰り返されたが、議論は「どちらが実用的か」という話にすり替えられた
- 「それはFieldingのRESTではない」（事実の問い）に対して「でも便利だから」（実用の問い）が反論として機能してしまう構造がある
- 事実の問題が価値判断の問題に置換されることで、誤用は誤用のまま定着し続けた
■ 9. 三つの問いの区別
- 混同されている三つの問い:
- 事実の問い: Fieldingの論文は何を書いていたか
- 実用の問い: CRUD-over-HTTPは便利か
- 命名の問い: それを「REST」と呼ぶ必要があったか
- 実用の問い（2番）の答えは「はい」であるが、2番が正しいことは事実の問い（1番）や命名の問い（3番）への回答にはならない
- 「REST論争」ではこの三つが「学術的な正しさ vs 実用性」という二項対立に圧縮されてきた
■ 10. Fieldingの回顧
- 2017年のESEC/FSE講演でFieldingは「RESTはバズワードになった。別にかまわない——この私か、私と働く人間でさえなければ」と述べた
- 2021年のツイートスレッドでFieldingは以下を述べた:
- RESTはAPIについてのものではなく、ネットワークベースのアプリにおけるシステム間の相互作用についてのものである
- APIが欲しい人々は「RESTから学べ」を「RESTを使え」と解釈してしまう
- 当時、開発者を読者として想定しないと決めたのはFielding自身であると認めた
- 「自分が対価を得ている理由は、自分の頭を使って自分のシステムの文脈に合わせた詳細を埋めていける能力があるからだ」と述べた