RESTは新たなSOAPなのか？

今から10年ほど前に、RESTとSOAPベースのシステムを中心とした活動の盛り上がりがあった。何人かの著者がそれぞれの長所と短所を書き上げたり、導入を検討すべきなのはどちらなのかを論じたりしていた。しかしながら、多くの注目がSOAPベースのWebサービスからRESTとHTTPに移行するにつれて、意見や議論は下火になり、多くのSOA実践者が分散システムの基盤としてREST(あるいはプレーンなHTTP)を採用するようになっている。そのような中でPakal De Bonchamp氏は先頃、“REST is the new SOAP”と題した記事を著して、RESTの適用を“狂気の沙汰(testimony to insanity)”だと断じた。

氏の記事は長く、内容も詳細にわたるが、その要点となっているのは、RPC機構ならば“数時間”でできる単純なAPIの提供が、RESTを使うことによって複雑で時間のかかるものになるという氏の見解である。なぜだろう？理由は次のとおりだ。

標準もなければ、詳細な仕様もありません。漠然とした“RESTful哲学”と、尽きることのない形而上学的議論、無様な回避策の山があるのみです。

メソッドをCRUD操作にマッピングするのは単純な作業ではない。既存のリソースを再利用せずに新たなリソースインスタンスを生成するのか、それをいつ行うか、どうやって判断すればよいのだろう？HTTPのエラーコードは限定的で、詳細なエラー状況を表すには問題が多い、というのが氏の見解だ。氏のリストはさらに続く。その結果は？

何時間もかけて、車輪の再発明を行うことになります。目的にぴったりでもなければスマートでもない、壊れていて、もろく、理解するには山のような資料が必要で、それとは知らずに仕様に反している車輪です。

続いて氏は、PUTなど特定のHTTP動詞を詳細に検討している。ただしPATCHやDELETEについてはほとんど取り上げていない。

リソースの更新にPUTを使いたいですか？OK。ですが、RESTの聖典(Holy Specifications)によると、データ入力はGET経由で受信した表現と同じでなければなりません。では、GETが返す多種多様な読み取り専用パラメータ(生成時刻、最終更新時刻、サーバの生成するトークン、...)はどうすればよいのでしょう？省略して、PUTの原則を破りますか？何らかの方法で加えておいて、サーバ側の値と一致しなければ、“HTTP 409 Conflict”を期待しますか(GETを発行しなくてはなりませんが...)？適当な値を設定して、サーバが無視してくれるように(無音エラーという幸運を)祈りますか？どれを選ぶにせよ、RESTが読み取り専用について何も考えていないことは明らかです。これは当分の間、修正されることはないでしょう。その一方でGETは、その前のPOST/PUTで送信されたパスワード(やクレジットカード番号)を返送する危険性をはらんでいます。このような書き込み専用パラメータについても、幸運を祈る他ありません。PUTには競合状態に陥る危険性があることも忘れてはなりません。いくつかのクライアントが違うフィールドを更新したいだけなのに、互いの変更を上書きしてしまったらどうしますか？

エラー処理、RESTのアーキテクチャ上の概念、その他多くの側面を詳細にレビューして、問題点が指摘されている。RESTの支持者も、信じていない者にも、一読の価値のある記事だ。そして氏は、次のように結論付ける。

ほぼ透過的なRPCは99パーセントの人々が本当に求めていたものであり、既存のプロトコルは、例え不完全であったとしても、十分に機能するものでした。Webの最底辺の共通分母であるHTTPへの極端な執着がもたらしたものの大部分は、時間と知力の壮大な無駄遣いです。RESTは簡潔をうたいながら、複雑性をもたらします。
RESTは堅牢性をうたいながら、脆弱性をもたらします。
RESTは相互運用性を約束しながら、実際には異種性をもたらしているのです。
RESTは新たなSOAPなのです。

記事への多くのコメントを読むと、一部に賛成する意見があるのは確かだが、大半は氏の意見に同意せず、さまざまな欠点を指摘している。例えばFilippos Vasilakis氏は、次のように述べている。

Royの論文を読んでみるべきです。あなたがここで攻撃しているのは、RESTに対する一般的な誤解です。Royが論文で述べているように、RESTはすべてのケースには適合しないかも知れませんが、クライアントをコントロールできないような場合には非常に適しています。自己記述的であるがために進化の可能なモデルが他にあるならば、教えて頂きたいものです。RESTはまさにそれなのです。私たちがコントロールしない、あるいはコントロールできないデバイスやクライアントやハードウェアと通信するためにRESTはあるのです (Apple Storeのアプリのように。Apple Storeでモバイルアプリのアップデートを配信するには10日間が必要です – ただしAppleに拒否されたり、アクセスやアップデートのできないセンサデバイスに妨げられなければ、ですが)。このようなシナリオのためのRESTであって、GraphQLでは制限や問題が多いのです。発展性に関する問題を解決するモデルが他にあるのならば、ぜひ教えてください。RPCはそのひとつではありません。

もうひとつのコメントは、Vlad Ko氏からのものだ。

いったい何を読んだのですか？まともなAPIを設計するために時間を費やすことが不満なのですか？それはあなたの責任であって、開発者としての目標ではないのでしょうか。RESTに関連するものや“関連しない”もの、ありとあらゆる問題に不満を連ねるのは、幼稚で無意味な行動です。どんな言語、プロトコル、仕様、コンセプトにも不満は現れます。問題やバグ、構文が非論理的、VMが遅い、型がない、厳格過ぎる、簡略的過ぎる、機能が多過ぎる、十分にOOPでない、など。それらがあればこそのソフトウェアエンジニアリングなのです。

Christopher Patti氏からは、

すばらしい記事です。表現はやや乱暴ですが、多くの裏付け証拠を揃えて、合理的かつ詳細に意見を述べています。ですが、ひとつだけ議論から漏れているものがあります – ツーリングです。SOAPという論理的純粋性の模範を人々が見限る、あるいは見限ったのは、この記事の内容を信じるならば、Javaや.NETのツーリングでの開発作業があまりにも、本当にあまりにもひどいものだったからでしょう。よくなっているとは聞いていますが、人は苦痛を感じると、新しいツールを取り入れることで対処しようとするものです。私たちが不幸な道を選んだのかも知れない、離れるべきだ、と主張していますが、ではどうすればよいのでしょう？新しいプロトコルをいくつか引用していますが、私が知りたいのは、SOAPあるいはRESTを直接的に置き換えることのできる、具体的な例なのです。

コメントだけでなく、さまざまなソーシャルメディアプラットフォームでもこの記事が取り上げられた。ついにはWeWorkのプラットフォームエンジニアであるPhil Sturgeon氏が、オリジナルの記事での主張を否定したい人々の要求を受け入れる形で、“A Response to REST is the new SOAP”という記事を著すことになった。

RESTとHTTPに関してありがちな誤解が、この記事全体にたくさん見られます。こうした混乱を通じて、人々を教育しようとこれまで務めてきたのですが、いまだ蔓延し続けているようです。私の発言力が十分ではなく、書き物も行動も不十分であることは確かです。これらは私自身の書籍に対する不満であって、著者に向けたものではありません。

元記事に匹敵する長さの記事で、氏は、元記事で詳細に議論されたRESTの問題を検討している。例えば、記事中の“壊れてもろい車輪”を作る件については、次のように述べている。

確かにイライラします。ドキュメントは不要であると説明されているため、REST APIは嘲笑されることも少なくありません。REST APIでは確かにドキュメントは不要であるべきですが、私自身はここ数ヶ月間、開発中のAPIのドキュメント作成に費やしています。それらがすべてRPC APIだからです。APIが独自に状態を持ち、そのアフォーダンスの宣言にハイパーメディアを使用し、コントラクトを提供するのであれば、可読性のあるドキュメントを生成するという選択も可能ですが、それが必要なのはREST APIをRPC APIのように処理する場合だけです ...多くの人が行っているように、仕様の不明確なRPCをRESTと偽っているのでない限り、REST APIは文書をほとんど必要とはしません。

PUTその他の危険性に関する元記事の議論については、“どうやらPUTの目的を理解していないことから生まれた不満のようだ”。反論はさらに続く。実際に、元記事を読んでいなかったとしても、氏の反論はそれ自体が一読の価値のあるものだ。しかしながらその議論の根底にあるのは、RESTに関する元記事の不平不満は、すべてではないにせよ、大部分が誤解によるものだ、という指摘である。記事は次のように結論付けている。

RESTが複雑な問題であることは確かです。RESTを理解していると自分では思っていて、それを理解していない人に出会った時に誤った評価を下す人が多過ぎるのです。そこら中で作られているREST風のAPIは、実際にはRPC + HTTP動詞 + 洒落たURL に過ぎません。それが大した役に立たないからと長編の記事を書いて、使いものにならない理由をつらつら書き並べるというのは ...

確かにそうなのかも知れない。しかしながら、両氏の議論はさらに続いているようで、Philは記事の更新を続けている。

著者とは建設的な対話を続けていて、RESTの仕組みについて理解してくれているようです。読者の中にも興味のある方がいるかも知れません。

関心のある読者はそれをチェックして、対話が進む様子を見るのもよいだろう。