GAE開発の落とし穴
Googleのクラウド環境をつかったGoogle App Engineによる開発するにあたり、初めての試みで苦悩する開発者達の経験をもとに、各開発フェーズにあわせて問題点やどう解決したかをご紹介します
News
ブックマークされました！
ブックマークがエラーになりました。もう一度お願いします。
RESTの良い点、悪い点、ひどい点
作者 Boris Lublinsky , 翻訳者 竹中 翔 - (株)ポータルアイランド 投稿日 2009年6月1日
Arnon Rotem-Gal-Oz氏はこの新たな投稿の中で、RESTに対する彼の考えを述べた （Arnon氏のRESTに関する考察の詳細は、ここから参照できる）。
Arnon氏によれば、RESTには３つの利点がある。
- 統合の相対的な容易さ
...すぐれたRESTful APIは最初のURIから発見できます。ただしこれは、サービスを呼び出すアプリケーションが何をするサービスなのか自動的にわかるということではありません。サービスを統合するためにAPIを利用している開発者が楽になることを意味しています。特に、ハイパーメディアによって次にすべきことのロードマップが提供されれば。
- ユビキタス標準の使用 - HTTPはRESTの最も一般的な実装である
WebのプロトコルであるHTTPについて言えば、JSONやATOMPubで発信することは、どんな言語やプラットフォームにおいても、サービス接続に使用可能なライブラリを簡単に見つけられることを意味します。
- 拡張可能性
...ステートレス通信、複製レポジトリはすぐれた拡張可能性を生み出します。
Arnon氏はRESTの欠点についてもいくつか述べている。氏の見解によると、RESTには主に２つの欠点がある。
- HTTP上のREST特有の"Lo-REST"実装（GETとPOSTしか使っていない）
技術的にはまだRESTfulなのですが、私にとって２つの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氏の投稿の中で、氏は実装のための適切なアーキテクチャを採用するためのすぐれた架空の議論を提示する。
関連情報
世界の先進エンジニアが集結 - QCon TOKYO 2012 早期割引実施中！
【豆蔵】「オブジェクト指向を現場で活かすリファクタリング入門」新規講座キャンペーン中
No comments
スレッド表示 返信