数年前、Ganesh Prasad氏はインターネットはRESTより基礎的かどうかを問うた。その後も氏はRESTやSOA、最近はクラウドについて、RESTの原則を支持しながら議論を続けてきた。近頃、LinkedIn REST Architectsグループにポストされた"RESTの欠点は何か?"という質問に対して、氏は次のように、自身のブログの内容を繰り返すことで答えている。
RESTには"欠点"のようなものがあるとは思いません。RESTはRESTという名が示す通りに上手く動作しています。しかし、RESTアーキテクチャの実装はHTTPプロトコルしか使わないことは覚えておくべきです。将来は他のプロトコルを使う実装を構想することができるでしょう。そこでは何かしらの改善が行われるはずです。
氏は続けて、改善の余地がある4つの領域について話す。ちなみに氏はRESTとREST/HTTP、すなわちREST over HTTPを同一視している。
- "HTTPは同期の要求/応答プロトコル。つまり、サーバ側で始まる通知の仕組み(ピアツーピア)を持っている。しかし、このような仕組みは常に必要とされる。よってRESTアプリケーションはWebhooksのようなアプリケーションレベルのデザインパターンが必要となる。現在、WebSocketsという双方向のトランスポートプロトコルがあり、おそらく、WebSockets上で動作し、RESTの原則に従うアプリケーションプロトコルのレイヤが必要とされる。"WebSocketsとRESTに互換性があるかどうかについての議論がここ数年、わき上がったことを踏まえると、これは面白いことだ。
- 氏はRESTコミュニティはウェブサービスのスタックから学ぶことがあると考えている。"SOAP+WS-Addressing "メッセージ"の上にはエンドツーエンドのプロトコルがあります。"これは、過去に同じような指摘がされている。氏はウェブサービスがWS-Addressing、WS-ReliableMessaging、WS-SecureConversation、WS-Policyを使う方法とインターネットのTCP、IP、IPSecの間にあるアナロジーについて説明している。氏はRESTアプリケーションの冪等性は信頼性という点で優れており、RESTにもトランザクションの代替があるはずだと考えている。しかし、次のようにも書いている。
しかし、セキュリティの問題が残ります。WS-SecureConversationとWS-SecurityはSSL/TLSとは違い、ルーティングに対応しています。SSL/TLSはRESTにとっての唯一のセキュティの仕組みです。WS-Sec*の場合、メッセージは部分的に暗号化され、コンテンツベースのルーティングやスイッチングができるように一部は暗号化されていません。このような仕組みはRESTにはありません。SSLはポイントツーポイントで、プロキシで検証できませんし、RESTの原則に反しています。
この考えが興味深いのはResteasyのBill Burke氏のような他の論者はRESTはセキュリティに対してより良いアプローチが必要だと考えいてるからだ。しかし、Ganesh氏はRESTとQoSについて話を進める。
RESTがQoSをサポートできないのは、*会話の状態*を維持しなければならないからです。状態を持つことは欠点とされます(スケーラビリティや障害復旧に影響を与えるから)。しかし、RedisのようなNoSQLデータストアが登場したことで、会話の状態をメモリからデータストアに移譲し、QoSのためだけに複数のノードでセッションを共有するができます。
残りの2つの領域については、
- 氏はHTTPの動詞は少なすぎると考えている。特に、ピアツーピアのインタラクションをしたい場合だ。そこで、いくつかの提案をしている。"INCLUDE (リソースコレクションへ追加をして、サーバが決めたURIを返す)、PLACE (リソースコレクションにクライアントが定義したURLと共に追加する)、REPLACE (全部)、FORCE (PLACEまたはREPLACE)、AMEND (部分更新。リソースのサブセットに対する操作を行うための動詞を定義する、コンテナ動詞)、MERGE (リソースの一部を与えられた表現に移植する)、RETIRE (DELETEよりも良い表現)、SOLICIT (GETの代替。コンテナ動詞。応答相手に要求元のリソースに対してしてほしい操作を要求する)"
- "HTTPはアプリケーションレベルとトランスポートレベルのステータスコードが合わさっています(304 Not Modifiedと400 Bad Request、407 Proxy Authentication Requiredと502 Bad Gateway)。RESTの他のプロトコルでの実装はアプリケーションプロトコルとトランスポートプロトコルの明確に分離して設計するべきです。HTTPは2つの義務を負い、結果はエレガントではありません"
HTTP 2.0の初期草案を見ても、Ganesh氏の提案は考慮されていないようだ。しかし、Ganesh氏自身が5年に渡って、提案仕様の作成に携わっている。
私はどのようなトランスポートにも(Pub/Sub, 非同期のポイントツーポイント、同期の要求/応答)対応する新しいアプリケーションプロトコルのためのInternet Draftの作成に携わっています。この新しいプロトコルは私がROMA (Resource/Representation-Oriented Messaging Architecture)と呼ぶ、新しい分散コンピューティングアーキテクチャの一部で、データモデルとメッセージAPIだけではなく、もっと高いレベル(QoS、説明、プロセスの協調)までカバーしています。
この草案が公表されたら、既存の課題にどのように対処しているか、RESTコミュニティからの評価がどうなのか、確認するのは面白いだろう。