BT

RESTの代替は必要か

| 作者: Mark Little フォローする 12 人のフォロワー , 翻訳者 徳武 聡 フォローする 0 人のフォロワー 投稿日 2014年1月6日. 推定読書時間: 4 分 |

原文(投稿日:2013/12/29)へのリンク

SoapUIの開発者であるOle Lensmar氏が最近、RESTは"利点を失いつつあるのではないか"、RESTの代替が必要なのではないか、という問いを投げかけている。

公開APIを構築するための有力な方式としてのRESTはほかのAPI技術を見劣りさせています。企業向けのシステムでは、ほかの方法(主にSOAP)も未だに使われていますが、RESTのアーリーアダプターはほかのAPI方式に対しては断固受け入れないスタンスを取り、RESTを採用してフォーマットにはJSONを使います。

氏はSOAPやXML-RPCのようなほかの方式ではなくて、RESTが成功した理由を説明している。しかし、氏はRESTが利用しにくい領域も多くあり、そのような領域ではほかの方法が必要だと考えている。

  • 非同期API: "従来のリクエスト/レスポンスではなく、データを非同期で押し出さなければならない場合、RESTfulな設計はうまく適用できません。さらに、基盤技術(WebSockets, MQTT, AMQP, Stomp, pubsubhubbub/WebHooksなど)はHTTPとはまったく異なるので、RESTの原則とは普通、相容れません。"
  • オーケストレーションAPI: "従来のREST APIが提供するリソースの粒度には利点はない。要求されたリソースをモバイルのダッシュボードや複雑なシングルページウェブアプリケーションから取得するには多くのAPIリクエストが必要。この場合、クライアントのロジック、帯域、サーバ処理にオーバヘッドが発生します。"
  • SDK vs API: "ほとんどのAPIの利用者はハイレベルな言語から利用します。したがって、各言語向けのクライアントライブラリを含む多くのAPIプロバイダが生まれます(Google、Facebookなど)。言語自体がRPC指向なので、SDKが提供するコードレベルのAPIも同様RPC指向になってしまいます。すると、おそらくは、最適化されたバイナリプロトコルを利用して、あるいは、RPCライクにHTTPリソースを使うことで(例えばJSON-RPC)、バックエンドのAPIも同様の動作をするように作ってしまいます。"
  • バイナリプロトコル: "[...] 例えばIoTデバイスやSDKからのリクエストに対応するために最適化されたメッセージ転送を行うため、バイナリプロトコルはより注目を集め、利用されるようになっています。" Apache Thrift, Google Protocol Buffers, Apache Avroなどのプロトコルだ。"上述した非同期APIのいくつかはバイナリフォーマットを利用しています。デバイスやサービスによって背負わされた帯域や処理の制限に対応するためです。"

氏はリアルタイムの要件のため、プロトコルとしてThriftを利用しているEvernoteを例示する。氏は、Daniel Jacobson氏のEvernoteのRESTlessな設計についての記事に言及している。

[...] REST APIは不特定多数の開発者を相手にする場合は優れた方法だと思います。しかし、利用者が特定のユーザや市場、産業や技術だけに限定されている場合、もっと具体的な解決策を選択するのは合理的なやり方です。性能や使いやすさ、セキュリティの面で競合より優位に立てるかもしれません。

氏は、とりわけAPIの設計では、ひとつの側面がすべてに適用できることはないということを認める。"私たちのような情熱的な技術者にとって幸運なのは、新しいことを学び、それをすべての利害関係者にとって最適なかたちで利用することで、私たちの世界はよりしっかりする(すくなくとも私の世界は)ということです。私はこのような多様性のある環境を否定しません。大歓迎です。"

コメント欄では氏に賛成するコメントもある一方、賛成しないコメントも多い。例えば、John Sheehan氏は、

私はEvernoteはRESTを捨てたとは思いません。最初から使っていなかったのではないでしょうか。使っていなかったのにもしっかりとした理由があると思います。Webhooksはとても‘REST’っぽい(最低でも一般的な理解では)です。非同期についての解説であなたが挙げた一覧はほとんどの一般的な実装には適用できません。

Darrel Miller氏はRESTと"ポピュラーなREST"の違いを示そうとしている。

私がDaniel Jacobson氏のオーケストレーションレイヤから言えることは、長い間、私がRESTfulな(そしてハイパーメディア駆動)APIを構築する上で利用してきた方法にとても近い、ということです。人々が“ポピュラーなREST”の誇大広告はFieldingのRESTの特性を何も変えていないことに気付き始めているからです。

多くのコメントがOle氏が真のRESTfulな原則とRESTfulと言われているが実際はそうでない実装を区別していない、と指摘している。あなたはどう思うか。すべての領域でRESTは利用できるのだろうか。あなたのおすすめを教えてください。

この記事に星をつける

おすすめ度
スタイル

こんにちは

コメントするには InfoQアカウントの登録 または が必要です。InfoQ に登録するとさまざまなことができます。

アカウント登録をしてInfoQをお楽しみください。

あなたの意見をお聞かせください。

HTML: a,b,br,blockquote,i,li,pre,u,ul,p

このスレッドのメッセージについてEmailでリプライする
コミュニティコメント

HTML: a,b,br,blockquote,i,li,pre,u,ul,p

このスレッドのメッセージについてEmailでリプライする

HTML: a,b,br,blockquote,i,li,pre,u,ul,p

このスレッドのメッセージについてEmailでリプライする

ディスカッション

InfoQにログインし新機能を利用する


パスワードを忘れた方はこちらへ

Follow

お気に入りのトピックや著者をフォローする

業界やサイト内で一番重要な見出しを閲覧する

Like

より多いシグナル、より少ないノイズ

お気に入りのトピックと著者を選択して自分のフィードを作る

Notifications

最新情報をすぐ手に入れるようにしよう

通知設定をして、お気に入りコンテンツを見逃さないようにしよう!

BT