原題: Roy Fielding’s Misappropriated REST Dissertation
著者: TwoBitHistory
公開日: 2020年6月28日
ソースURL: https://twobithistory.org/2020/06/28/rest.html
アーカイブ日: 2026-03-01
RESTful APIはいたるところに存在する。しかし、「RESTful」が本来何を意味するのかを本当に理解している人は、どれほどいるだろうか？
この記事は、Roy Fieldingの2000年の博士論文（カリフォルニア大学アーバイン校）をもとに、RESTという概念がいかにして誤解され、本来の意図から切り離されて広まったかを丁寧に解説する。著者はFieldingの原典を読み込んだうえで、「RESTが広まった経緯よりも、Fieldingの思想がいかに誤読されたかのほうがずっと興味深い」という逆説的な結論に至る。
多くの人が「FieldingはWebサービスAPIをREST方式で構築することを提唱した」と思い込んでいるが、これは事実誤認だ。
論文のタイトルは「Architectural Styles and the Design of Network-based Software Architectures」であり、その主題はWebサービスAPIではなくHTTP自体のアーキテクチャである。
Fieldingは HTTP/1.0 仕様の策定に貢献し、HTTP/1.1 仕様の共同著者でもあった。彼の関心は「HTTP/1.1 の設計プロセスを導いたアーキテクチャ上の原則の蒸留」にあった。RESTはその原則の体系化であり、HTTPを拡張するためのガイドとして提案されたものだ。
具体的には、Fieldingは MGET・MHEAD という新メソッドによるリクエストのバッチ化提案を却下した。理由は「RESTが定めるメッセージのプロキシ可能性・キャッシュ可能性の制約に違反するから」だ。代わりにHTTP/1.1は、複数リクエストを送信できる持続的接続として設計された。また、クッキーについても「状態を持つべきでないRESTシステムに状態を持ち込む」として非RESTfulだと批判したが、すでに普及していたため受け入れた。
論文のもうひとつの大きな誤解は、「RESTはあらゆるネットワークアプリケーションに使える汎用アーキテクチャだ」という思い込みだ。
Fieldingは論文の中で、RESTは分散ハイパーメディアシステムを前提として設計されたと明言している。要するに「我々はHTTPを設計した。もしあなたも分散ハイパーメディアシステムを構築するなら、RESTを使うといい」という提案だった。
RESTが解こうとした問題は「アナーキックな拡張性（anarchic scalability）」——組織・国境を越えてドキュメントを高パフォーマンスで接続すること——だ。この問題は、公開向けWebサービスAPIには確かに当てはまる。しかし、自社クライアントとだけ通信する内部バックエンドには必ずしも当てはまらない。
さらに言えば、論文の主題はRESTそのものではない。論文の大半は「ソフトウェアアーキテクチャのスタイルの分類学」に費やされており、REST自体が語られるのはたった1章だ。分類学に並ぶスタイルには、Pipe-and-Filter (PF)、Layered-Client-Server (LCS)、Client-Cache-Stateless-Server (C$SS)、Layered-Client-Cache-Stateless-Server (LC$SS) などがある。
RESTは実のところ、Uniform-Layered-Code-on-Demand-Client-Cache-Stateless-Server (ULCODC$SS) とでも呼ぶべき派生スタイルだ（さすがにその名前は採用されなかったが）。
Fieldingが強調した核心的メッセージは「一つのアーキテクチャスタイルをすべてに使うな。アプリケーションの要件に合ったスタイルを選べ」だった。その皮肉として、今日RESTはまさに「どんなアプリケーションにも使われるシルバーバレット」になってしまっている。
では、なぜWebサービスAPIの世界でRESTがこれほど広まったのか。著者は「FIOH（Fuck It, Overload HTTP）仮説」を提唱する。
2000年代中盤、SOAPへの反発が起きた。SOAPは冗長で複雑なXMLプロトコルであり、それを採用した企業（エンタープライズ）への反感も相まって、多くの開発者がSOAPから離れた。Ruby on Railsは2007年にSOAPサポートを廃止し、創設者のDavid Heinemeier Hansssonは「SOAPは過度に複雑でエンタープライズに乗っ取られた」と明言した。
SOAPを捨てた後も、何らかの標準が必要だった。全員がHTTPを使い続けるのは確実だったので、最も単純な選択は「HTTPの既存のセマンティクスをそのまま使う」ことだった。それが実質的にFIOHだ。
しかしFIOHでは学術的な権威が感じられない。そこで、HTTP/1.1の共同著者が書いた、HTTPの拡張に「何となく関係する」論文——Fieldingの論文——が「学術的なお墨付き」として流用された。著者はこれを「正式な陰謀ではなく、マーケティング上の都合による流用」と評する。
この流用の証拠が、現代のRESTful APIに欠けているものに現れている。
HATEOAS（Hypermedia as the Engine of Application State）：Fieldingのオリジナル設計では、RESTシステムのクライアントはベースエンドポイントからリンクを辿って全エンドポイントを探索できるべきだ。これは「Representational State Transfer」の「State Transfer」が意味するもの——ハイパーリンクを使ってステートマシンをナビゲートすること——に直結する。しかし現代のRESTful APIでHATEOASを実装しているものはほとんどない。Fielding本人も「HATEOASなしはRESTではない」と批判している。
CRUDのHTTPメソッドマッピング：PUT vs PATCHのどちらがより「RESTful」かという議論は開発者の間で絶えないが、Fieldingの論文にはCRUDアクションとHTTPメソッドのマッピングについて一切記述がない。これはFIOHの発明物であり、RESTの一部ではない。
著者の結論は建設的だ。「RESTを誰も理解していない」ではなく、「RESTという言葉が流用された」と考えるべきだ、と。
RESTful APIが本当に適しているのは、HTTPが解こうとした問題と同様の問題——組織・国境を越えたAPIの提供——を抱える場合だ。公開向けAPIには予測可能で均一なインターフェースをRESTで提供する合理性がある。
しかし、自社クライアントとだけ通信する内部バックエンドには、GraphQLやJSON-RPCのほうが適しているかもしれない。Fieldingが言ったように「形は機能に従え」——要件から始めてアーキテクチャを選ぶべきだ。
「みんな使っているけど誰も正確に理解していない概念」の典型として、RESTはこれ以上ない例だ。この記事の価値は、単に「RESTが誤用されている」と指摘するだけでなく、なぜそうなったのかを歴史的・社会的な文脈で説明することにある。
SOAP嫌いの開発者文化、「エンタープライズへの反発」、学術的権威を借りたいという動機——このような複合的な要因の積み重ねが、Fieldingの思想がその本来の文脈から切り離された経緯を説明している。「正式な陰謀ではなくマーケティング上の都合」という著者の表現は、ソフトウェア業界における概念の普及が、どれほど意図せぬ形で起きうるかを端的に示している。
また、HATEOASとCRUDマッピングをめぐる「REST純粋主義者 vs 実用主義者」の論争も、この視点から見ると全く違って見える。両者とも、前者は「オリジナルのREST」、後者は「流用されたFIOH」について話しており、そもそも同じものを議論していなかったのだ。
原典を読んだ人が書いたこの記事は、「自分はRESTを知っている」と思っている全ての開発者に、もう一度立ち止まって考える機会を与えてくれる。
タグ: #REST #HTTP #WebAPI #ソフトウェアアーキテクチャ #歴史 #SOAP #HATEOAS