後にオラクルのSOA戦略の中心となるCollaxa社のBPEL製品に関わる主要人物の一人であったEdwin Khodabakchian氏は、独立して、ここ数年、「twitterやGoogle Readerを組み合わせて雑誌のように仕立て上げる」Feedlyの開発に携わっている。先日、Edwin氏は、JSONベースのWebサービス構築のベストプラクティスに関する、彼の経験をもとにしたクックブックをブログに投稿した。このクックブックは、まだ未完成だと思われるが、現在のところ以下のようなガイドラインを提供している。
フェーズ1 - 単純なリソース／サービスの定義 ｜ 顧客情報をリソースの例にとり、これをJSON形式で設計してみましょう。単純なサーブレットを作成します。このサーブレットでは、PUTで新規顧客を作成し、GETで顧客のキー値にもとづいて顧客情報を返し、DELETEで顧客を削除し、POSTで顧客情報を更新します。PUTでは、新規に作成された顧客リソースを表すURLの正確な情報を返すようにしましょう。私たちの場合は、JSONをJavaのモデルにマッピングするフレームワークをもっており、hibernateによってそのモデルをMySQLデータベースに永続化しています。このフェーズで重要なことは、JSON表現を正確に行うことと、ベースURLの表現を単純できれいにしておくことです。
続いて以下のようなガイドラインが示されている
フェーズ3 - 検証の追加 ｜ サービスの実装を変更し、PUTやPOSTで受け取ったJSONリソースのデータを検証するロジックを追加しましょう。例外に関する情報を定義しクライアントに返すために、HTTPエラーコードの使用方法を学びましょう。さらにクライアント側でのこれらの例外の処理方法を学びましょう。このフェーズで重要なことは既存のHTTPエラーコードに関する知識をもち、既存のエラーコードが利用できる場合にはそれらを利用し、必要な場合にはHTTPに準拠した新しいエラーコードを定義することです。
現時点で、この投稿には、7つの独立したフェーズが定義されており、既に紹介した最初のフェーズから、認証に関するフェーズ、ライフサイクルに関するフェーズまで多岐にわたっている。実際の経験に基づいたガイドラインを読むのはすばらしいことだ。Edwin氏は過去に彼らを悩ませたであろう以下のような事柄に関しても言及している。
抽象化されたXMLHTTPRequestを扱うための多数のライブラリが存在します。例えば、クロス・ブラウザ対応のためのものや、呼び出しているGET、POST、PUT、DELETE操作の内容を表示してくれるものです。
他にも次のような点に言及している
ビジネス・イベントに対する適切な粒度を定義することや、正しくデータ型を定義することはたいへん難しいことです。適切な結果を得るために、数回、定義をやりなおさなければならない場合もあります。私からのアドバイスは、最初から過度に作り込みすぎないことです。可能な限り単純に作っておいて、新たな利用方法がでてきた場合には、リファクタリングすればよいのです。
もちろん、ほとんどのREST支持者が当然のことと見なしているRESTの様々な側面に関しても言及している。次のようなものだ。
フェーズ5 - キャッシュの追加 ｜ Webの基盤は、高機能なキャッシュの仕組みを提供しています(最終更新情報や、キャッシュ期間、ETag)。これらの仕組みを学び、利用することで、サービスのパフォーマンスや拡張性を改善できないかを検討しましょう。
また、Edwin氏は一見したところREST/HTTPのルールそのものに反するのではないかと思えるような、非常に実践的なアプローチについても言及している。
サーバによっては、DELETEを許さないものもあります。こういった場合には、メソッドのオーバーライトによってPOSTを発行する方法を学ばねばなりません。
Edwin氏によると、彼らの使っているバックエンドの基盤の一部をオープンソースとして公開することを検討しているとのことだ。それまでは、FriendFeedのAPIドキュメントが利用可能だ。ますます高まるJSON＋RESTの人気と相まって、この興味深いクックブックは開発者にとって検討、活用する価値のあるものとなるだろう。