BT

最新技術を追い求めるデベロッパのための情報コミュニティ

寄稿

Topics

地域を選ぶ

InfoQ ホームページ ニュース RESTの良い点、悪い点、ひどい点

RESTの良い点、悪い点、ひどい点

ブックマーク

原文(投稿日:2009/5/20)へのリンク

Arnon Rotem-Gal-Oz氏はこの新たな投稿の中で、RESTに対する彼の考えを述べた (Arnon氏のRESTに関する考察の詳細は、ここから参照できる)。

Arnon氏によれば、RESTには3つの利点がある。

 

  • 統合の相対的な容易さ
    ...すぐれたRESTful APIは最初のURIから発見できます。ただしこれは、サービスを呼び出すアプリケーションが何をするサービスなのか自動的にわかるということではありません。サービスを統合するためにAPIを利用している開発者が楽になることを意味しています。特に、ハイパーメディアによって次にすべきことのロードマップが提供されれば。
  • ユビキタス標準の使用 - HTTPはRESTの最も一般的な実装である
    WebのプロトコルであるHTTPについて言えば、JSONやATOMPubで発信することは、どんな言語やプラットフォームにおいても、サービス接続に使用可能なライブラリを簡単に見つけられることを意味します。
  • 拡張可能性
    ...ステートレス通信、複製レポジトリはすぐれた拡張可能性を生み出します。

Arnon氏はRESTの欠点についてもいくつか述べている。氏の見解によると、RESTには主に2つの欠点がある。

 

  • HTTP上のREST特有の"Lo-REST"実装(GETとPOSTしか使っていない)
    技術的にはまだRESTfulなのですが、私にとって2つのHTTPメソッドでは本当に有益だとは思えません(実は多くの実装をunRESTfulにします)。
  • 現在のプログラミング言語の制限
    ...プログラミング言語はリソース指向ではないので、URIとマッピングするコードは汚くなりがちです。言い換えると、REST APIをハイパーテキスト駆動にするのは比較的難しいのです(これはRESTの制約です)。

最後にArnon氏はRESTのひどい部分を指摘した。これらのほとんどはRESTの誤用によって促進される。

 

  • 熱狂的な支持者(Arnon氏によって使われた用語で、RESTの議論がしばしば宗教的が宗教的であることを表す)
    RESTだけではなく、すぐれた技術やアイディア(AgileやTDDなど)は、お気に入りのアイディアを盛り込むのは素晴らしいことで、みんな自分たちのようにすべきだと考えている支持者たちのシェアを得ます。
  • RESTの誤解
    ...GETsfulな実装の構築(つまり全てhttpのGETで行います)やURIがコマンドである素のRPCの実行、HTTPメソッドを使ったCRUD操作の実行などなど。

Arnon氏は投稿を以下の主張で締めくくった。

RESTはシンプルに見えますがそうではありません。RESTは考え方の変化を要求します(例えばリソースの識別、状態遷移の具体化など)...RESTはあなたにとって重要で有用なツールとなります。しかし... どのアーキテクチャ/テクノロジとも同様に、よくない実装は全ての利点を打ち消してしまいます。

WS*対RESTの議論は終わりがないように思われるが、実際にはどちらも「あらゆるものへの回答」にはならない(「ハンマー」症候群を警戒せよ)。

... 完全なビジネスの全体論的視野をとった時、あなたは異なるアーキテクチャの原則がうまくフィットする場所を目にするでしょう。アーキテクチャスタイル(そしてアーキテクチャパターン)は課題を解決するために使う道具です。ハンマーを使うのが適切な場所はありますが、ハンマーよりも適切な道具があることを確認するのもまた賢明なことです。

例えば、ほとんどのRESTの実装は非同期呼び出しとイベントをサポートしておらず、結果として、イベント駆動型のアーキテクチャスタイルはおそらくREST向きではない。別の例として、SOAPエンベロープによって提供されるビジネスとインフラの関心事の分離は、RESTの場合は実装者に委ねられている。結果的に、REST向きではないような、将来変更される可能性があるインフラについての関心事の実装を要求される。

RESTはWeb 2.0、特にマッシュアップとAJAXの発展によって最近さらに人気を得た。この場合、RESTサービスはJavaScriptからアクセスされ、マーシャリングメカニズムとしてJSONが使用される。これを根拠に、REST支持者の多くは、RESTはおびただしい数のWS*標準を使う場合に比べ、サービスの呼び出しがより簡単であると主張している。これは「手で」サービス呼び出しコードを実装している場合には正しい。一方、WSDLからサービス呼び出しコードを生成するツールがあり、それが多くの言語を対象にしていれば、この作業は取るに足りないものになる。

 

REST対何かの例のリストには終わりがなく、それはリストの作者に大きく依存する。Arnon氏の投稿の中で、氏は実装のための適切なアーキテクチャを採用するためのすぐれた架空の議論を提示する。

この記事に星をつける

おすすめ度
スタイル

BT