CloudWatch.posterous.com

今、新しいサービスを作っており、REST APIを提供するサービスであるので、色々と調べています。なかでも参考になったのが、次のページですね。２００８年と少し古いのですが、、

RESTful Web サービスの基本

• REST Web service の最も純粋な形での具象実装は、次の 4 つの基本的な設計原則に従う

1. 明示的に HTTP メソッドを使う
2. ステートレスにする
3. ディレクトリー構造に似た URI を公開する
4. XML、JSON (JavaScript Object Notation) のいずれか、またはその両方を転送する

• 明示的にHTTPメソッドを使う
  • RFC 2616 による HTTP プロトコルの定義に従って明示的に HTTP メソッドを使う
  • HTTP プロトコルの定義どおりの方法で使う必要があります
  • REST での基本的な設計原則によって、CRUD (create、read、update、delete) 操作と HTTP メソッドとが 1 対 1 に対応付けられることになります

1. 1. 1. サーバー上にリソースを作成するためには POST を使います。
      2. リソースを取得するためには GET を使います。
      3. リソースの状態を変更、または更新するためには PUT を使います。
      4. リソースを除去、または削除するためには DELETE を使います。

1. • 残念なことに、多くの Web API に特有の設計上の欠陥は、HTTP メソッドが本来意図されていない使われ方をすることにあります
   • HTTP GETは通常１つの具体的なリソースを特定するが、サーバー上で何らかのトランザクションを開始するという美しくないWeb APIの事例が数多く有る
   • RESTfulな書き方の一例

変更前

GET /adduser?name=Robert HTTP/1.1

変更後

POST /users HTTP/1.1

Host: myserver

Content-Type: application/xml

<?xml version="1.0"?>

<user>

<name>Robert</name>

</user>

• • 一般的な設計原則として、HTTP メソッドを明示的に使うという REST のガイドラインに従うためには、URI の中では動詞ではなく名詞を使う方が賢明

• ステートレスにする
  • REST Web サービスは、より高いパフォーマンスを求める要求に応えるために、スケーラブルでなければなりません。
  • 仲介用のサーバーを使ってスケーラビリティーを改善するためには、REST Web サービスのクライアントは完全かつ独立したリクエストを送信する必要があります
  • つまり必要なデータをすべて含んだリクエストを送信する必要があり、そうすることによって仲介サーバーのコンポーネントは、リクエストから次のリクエストまでの間、ローカルで状態を保持しておかなくても、転送やルーティング、ロード・バランシングを行うことができます
  • ステートフル設計

•  
  • ステートレス設計

•  
  • ステートレスな Web サービスが生成するレスポンスには、複数ページの結果セットの中の次ページ番号へのリンクが含まれており、クライアントがこのページ番号を保持するために必要なことを行えるようになっています。RESTful Web サービスの設計に関するこうした側面は、上位レベルで 2 つの部分に分割することができ、それによってステートレスなサービスを維持するための方法を明確にすることができます。
  • サーバー
    • サーバーが生成するレスポンスには他のリソースへのリンクが含まれており、それによってアプリケーションは関連リソースの間をナビゲートすることができます。
    • サーバーが生成するレスポンスには、このレスポンスをキャッシュしておくことで、重複するリソースへのリクエストの数を削減したり、あるいは一部のリクエストを完全に削除したりして、パフォーマンスを改善することができるかどうかが示されています。サーバーはそのために、HTTP レスポンス・ヘッダーに Cache-Control と Last-Modified (日付の値) を含めます。
  • クライアント　アプリケーション
    • クライアント・アプリケーションは Cache-Control レスポンス・ヘッダーを使用して、そのリソースをキャッシュする (ローカル・コピーを作る) かどうかを判断します
    • クライアント・アプリケーションは、他のリクエストとは独立してサービス可能な、完全なリクエストを送信します。そのためには、クライアントは Web サービスのインターフェースで指定された HTTP ヘッダーを完全利用する必要があり、また完全なリソース表現をリクエスト・ボディーの中に入れて送信する必要があります

RESTful Web サービスをステートレスにするためには、クライアント・アプリケーションとサービスの間での、こうした協調動作が必須です。こうした協調動作によって帯域幅が節約され、またサーバー・サイドで保持されるアプリケーションの状態が最小限になるため、パフォーマンスを改善することができます。

取り急ぎ、調べた中では次の４つくらいが面白い記事でした。まだまだ技術寄りのブログなどは少ない状況ですね。これからか。。。

Ruby版PaaSの"Heroku"で無料Railsホスティング環境を手に入れよう - Social Change!

Herokuでアプリを立ち上げるまでの流れを簡単に説明しています。最初はここからやっているのも良いかも。

 Herokuで作るFacebookアプリ：第1回　Herokuを使ってFacebookアプリを作ろう｜gihyo.jp … 技術評論社

これは良いですね。既に第７回まで記事が出ており、Facebookアプリというテーマも面白そう。これはやってみる価値ありですね。

第3回 クラウドプラットフォーム「Heroku」の活用 | Think IT

こちらのまとめも良いですね。特徴と基本的な使い方がわかりやすくまとまってますね。

エンタープライズ市場におけるRubyの見通しは？ Heroku COOに聞いた ー Publickey 

読み物として面白いですね。Rubyの生産性の高さは今後、益々重要性が増してくると個人的には感じますね。  

考え方としてこうあるべきですね。

スマートフォンだけでなく、ワイヤレスだけでなく、サービスも含めて、トータルでビジネスモデルは考えるべきです。

顧客へのベネフィットを、どんな端末で、どんなインフラを通じ、どのようなサービスを提供するかという事をデザインした上で、自社の強み、コラボレーションするパートナーを戦略的に考えていく。

これまであまり、こういった事が語られてこなかった気がする。

メインフレームからクラウドへ...

今朝見た、記事に少しコメントしてます。

要求仕様が比較的安定しているプロジェクトは確かにあり、その際にはウォーターフォールでの問題は、確かに少ないです。

要は設計フェーズまでの戻りが、ほとんどないので、各フェーズの成果がきちんと積み上げられていくからです。

この記事では、要件が定まりにくいものは、アジャイルでやろうといった内容の記事が書かれていました。

実際のプロジェクトですと、同じシステムを何フェーズも開発していくの様な大規模システムですと、要件も定まりやすいものもあれば、定まりにくいものもでてきたりします。

結局は、初回の開発手法がズルズルと引きずられ、要件云々といった事で、開発手法を大きく変えるというのは、難しくなります。
もちろん、見積りの方法も変わるので、営業からも非難を浴びますww

そんな中で、「ウォーターフォール」において、いかに効率的に要件をきめ、設計まで落とし込んでいくのかという事で、最もユーザー部門から要望があがりやすい「UI」の部分を、画面回りのプロトタイプを作成しながら、View部分の要件を固める。

プロトタイプベースで、Viewにおけるユーザー部門と開発ベンダーとの認識相違をなくし、そこから、Modelを確定したら、バッチ部分の仕様のアウトラインが見えてくる。

ウォーターフォールの要件定義・外部設計フェーズでの「各部門の認識相違をなくす完璧主義」を実践する事で、ウォーターフォールの欠点を補う事もできたりします。

といった感じで、実際の現場で使ってる手法を少し紹介してみました。

以前、SOAに関するプロジェクトの企画立案をしていたこともあり、「SOAマニフェスト」が発表、SOAの意味が再定義された － Publickey この記事を見て、改めて考えてみました。

SOAを技術論からスタートしないこと。これは、SOAを実現するための最も重要なポイントだと思っています。データの二重管理といったことやリソースの共通化によるコスト削減など、直近のある意味小さなベネフィットばかりを見ていても、結果的には何も解決しないし、この記事でいうところの「戦略的な目標」が達成されないからです。

ビジネスバリューを第一に考えるからこそ、Service Oriented Architecutureが構築できるものですよね。 

関連記事

• 情報システム部門は「SOA」を改革の武器として使い始めた － Publickey

改めて、クラウドのテクノロジーや現在、提供されているサービスを調べ直しており、様々なサイトやブログを見ているのですが、やはりとてもわかりやすい内容で記事が掲載されているのが、Publickeyでした。そこで、Salesforceを例にあげて、マルチテナントアーキテクチャーに関する連載があったので、紹介しておきます。

MapReduceやキーバリュー型にデータベースに注目されているが、既存のリレーショナルデータベースを核に、クラウドを構築し、どのようにしてスケーラブルなシステムを構築しているかを説明した記事です。

知られざる「マルチテナントアーキテクチャ」（1）～SaaSはみんな同じではない？

セールスフォースがいかにスケーラブルであるのか、また、マルチテナントアーキテクチャーというのはどういったものであり、Salesforeが採用しているマルチテナントがどういう方式であるのかが説明されてます。

知られざる「マルチテナントアーキテクチャ」（2）～スケーラビリティのカギは組織ID

全てのユーザーが同一データベース、同一スキーマを利用しているSalesforce。これによりインフラの共有が可能となり、効率的な運用と低コストを実現しているが、それだけではスケーラビリティやアベイラビリティを実現することはできません。Oracleのパーティショニング機能とパラレル機能による分散処理技術について説明されています。

知られざる「マルチテナントアーキテクチャ」（3）～スキーマとメタデータの謎 

全ユーザーで同一のスキーマを利用しながら、個別の顧客のディマンドを許容する矛盾に、Salesforceはどのように答えているのか？スキーマとメタデータについて、説明されています。

まとめの最後に書かれていましたが、「最初からマルチテナントアーキテクチャーで設計したからできた」システムであるのは確かに思います。品質と性能の高いクラウドサービスとは、ここまで違うものであるということが、この記事によってよくわかりますね。

関連記事

• 【CCW2010 Osaka】セールスフォース・ベニオフCEOが説くクラウドの「本質」 : クラウド・コンピューティング - Computerworld.jp 

パラレルスは1月17日、クラウドサービス提供事業者を対象とした収益性向上のための資料(ホワイトペーパー)の無償提供を開始した。