「なぜ Resource 指向か」の編集履歴(バックアップ)一覧はこちら

なぜ Resource 指向か」(2008/12/29 (月) 11:07:53) の最新版変更点

追加された行は緑色になります。

削除された行は赤色になります。

http://www.rubywaves.com/why-resource-oriented-matters Why Resource-Oriented Matters Waves が伝えたい1つのことは リソース指向開発をより簡単にするよう努力していることです。しかし、最終結果は何でしょう?なぜ重要なのでしょう? リソース指向は WEB の構造です。 なので Web アプリケーションを書くのに重要になります。たまたま、WEB はとてもスケーラブルで拡張可能だということがわかりました。アプリケーションを構造化することで同じラインに並び(?)、属性を拾います。どうしてわざわざ一からやり直すのでしょう? あなたは多くの既存の WEB インフラを利用することができます。リソース指向のアプリケーションだけが本質的によりスケーラブルというわけではなく(?)、RSS のような標準的な代替キャッシュという既存技術をほとんど利用できます。 あなたはいろいろなオープンスタンダードのあるアプリケーションを作っています。 This obviously makes it much more likely that せいぜいマイナーチェンジで、他のアプリケーションで共同で簡単に利用できるよう望んでいます。 例えば、 URIs と MIME タイプは文字通り何百万もの既存アプリケーションで広く認識されています。 あなたのアプリケーションは、システム全体で変更の影響を減少させるので、維持するのはそれほど高価ではありません。これは「疎結合」と「共通インタフェース」の考えに基づきます。メッセージは自己説明的で、アプリケーション特有の RPC のようなインタフェースよりむしろ共有されて標準的な型を当てにします。例えば、あなたは新しいコンテンツタイプとクライアントをサポートに加えることができ、魔法にかかったように使用し始めるでしょう。(?)その上、新しいクライアントは特にそれらについて何も知らなくてもサービスを利用でき、ちょうどサーとエンジンがするように現在のWEBサイトを処理するでしょう。 このように、あなたが配布されたアプリケーションがスケーラブルで疎結合で拡張可能なアーキテクチャであると立証したいと思うなら、既存の豊富な技術とケーススタディを利用することができ、このことはオープンスタンダードとしてリソース指向が広く受け入れられます。(?) 欠点としては、リソース指向アーキテクチャは実装が難しい場合があるということです。ほとんどの既存のフレームワーク(Waves も例外でなく)では。REST やリソース指向アーキテクチャスタイルの一部を実装しているだけです。 これが Waves が生まれた理由です。:私たちの目的は真のリソース指向スタイルのアプリケーションを開発するのを簡単にすることです。 Waves は、出発点として MVC のような完全に異なったイディオムを使うよりは、リソース指向スタイルのアプリケーションを配ることを許します。

表示オプション

横に並べて表示:
変化行の前後のみ表示:
記事メニュー
目安箱バナー