- PR -

感想 Webの「正しい」アーキテクチャ

参照元記事 | 同じ記事を参照しているスレッド一覧
1|2 次のページへ»
投稿者投稿内容
autumn
大ベテラン
会議室デビュー日: 2001/07/27
投稿数: 215
投稿日時: 2002-11-07 11:20
　これは重要なポイントを突いた記事だと思いました。
　URIをCOPY&PASTEしても意味がないサイトって、けっこう腹が立ちますよね。面白いページを発見しても、それを容易に誰かに伝えられない訳ですから。トップページから、ページに到達する手順をいちいち説明するのは面倒ですし。
biac
大ベテラン
会議室デビュー日: 2001/10/22
投稿数: 106
投稿日時: 2002-11-08 13:48
引用:

　URIをCOPY&PASTEしても意味がないサイトって、けっこう腹が立ちますよね。面白いページを発見しても、それを容易に誰かに伝えられない訳ですから。

フレームも同じようなものですね。 なかには、親フレームに渡す GET パラメータで子フレームを指定出来るように工夫しているところもありますけど。

ところで、うちの若い社員に教えてもらったんですが、全検索結果： 吉松史彰 というリンクを貼ることができます。 Amazon.co.jp のアソシエイト・プログラムの一つ、Amazon.co.jp ベーシックリンク の「(4.)サーチ結果リンク」だそうで。
※ だからといって、記事の主旨が損なわれるとは思いません。
masayh
会議室デビュー日: 2002/03/30
投稿数: 10
投稿日時: 2002-11-08 16:11
BPMに見られるcontent-based dispatchなど、self-describingな表現力を基本とするSOAPと、WebのURIによる疎結合性の考え方は、本来両立しなければいけないはずですが、開発ルールやframeworkの実装上から、ここで指摘されるような問題が起こったのでしょう。URIだけでSOAP routingを実現しようとしたら、locatorによる間接参照の解決が、hop-by-hopで必要となってしまいます。それよりも、content-based routingの方がはるかに現実的だと思いますがいかかがでしょう。SOAPでは、URI namespaceによるmodularityはありますが、protocolに非依存であるので常にURIによるアクセスパスの指定には無理があります。たとえば、独自EDIでの転送を考えれば、このEDIでURI指定のアクセスパスを必須にしていなければ無意味になってしまいます。したがって、URIはもっと実装レベルより論理レベルの識別として扱わないといけないわけですが、いまのWebサービスにはprotocol非依存なこういう仕組みはありません。
biac
大ベテラン
会議室デビュー日: 2001/10/22
投稿数: 106
投稿日時: 2002-11-08 17:26
HTML のフォームで使えるメソッドは、 GET と PUT です。
その使い分けをどうすべきか、 参考までに引用しておきます。

まず、 W3C の規格 HTML 4.01 Specification から。
17.13.1 Form submission method
引用:

The "get" method should be used when the form is idempotent (i.e., causes no side-effects). Many database searches have no visible side-effects and make ideal applications for the "get" method.

If the service associated with the processing of a form causes side effects (for example, if the form modifies a database or subscription to a service), the "post" method should be used.

※ 副作用が無い場合には GET を使うべきだ、 データベース更新を伴うような副作用があるときには POST を使うべきだ、 というところでしょうか。 ( 英語が苦手な方は、 あちこちに邦訳がありますので、 検索してみてください。 例えば 「HTML 4.01 仕様書邦訳」 など。 )

もうひとつ、 いつもの本 「ユニバーサル HTML/XHTML」 から。
(その本の p.143 から引用しようと思いましたが、 ほぼ同じ文章が著者のサイトにありましたので、 それを。 f(^^; )
GETとPOSTの使い分け
引用:

getはその名の通り、何かをゲットする（取り出す）のが本来の役割です。データベースにキーワードを送って検索結果を「取り出す」などのためにgetを用います。
引用:
postは「投稿する」を意味します。メッセージの書き込み、新規データの登録など、何かをプログラムに送って内容を書き換えるような場合はpostを使わなければなりません。
引用:
検索などの常に一定の結果を伴うものはget、新しいデータの送信・登録はpostというのが原則です。

---
ASP.NET (魔法の杖) を使いこなすために…
ユニバーサル HTML/XHTML
NothingButXMLInfoSet
大ベテラン
会議室デビュー日: 2002/07/16
投稿数: 116
投稿日時: 2002-11-08 19:48
＃こんなスレがあったの知りませんでした。。。
皆様お読みいただいてありがとうございます。

autumnさん＞これは重要なポイントを突いた記事だと思いました。 ＜

どうも私のオピニオンて前向きじゃないんで、評判が気になっていたところでした。

biacさん＞Amazon.co.jp のアソシエイト・プログラムの一つ、Amazon.co.jp ベーシックリンク の「(4.)サーチ結果リンク」だそうで。 ＜

知りませんでした。ありがとうございます。

masayhさん＞＜

あー....ちょっと考えます。
しょむ
ぬし
会議室デビュー日: 2001/09/06
投稿数: 430
投稿日時: 2002-11-09 03:37
ひとくくりに「Web アプリ」といってもいろいろありますよ。
自由な遷移を許すと収集がつかなくなる、まるでネイティブアプリのような要求仕様とか。まぁ、既存システムを置き換える業務アプリ系にはありがちですが。

あらゆるページに固有の URI(Query 含む)を付けられ、そこで行う作業がその URI のみで特定できるようなモノって、けっこう制限あります。
まぁ、こういう作りができれば、他のスレにあった「複数ウィンドウによる同時アクセス」も実現できてなかなかいいんですけど。

「画面遷移」型ではなく「サイトマップ」型の設計をすればいいんでしょうね。

[ メッセージ編集済み 編集者: しょむ 編集日時 2002-11-09 03:39 ]
tai
会議室デビュー日: 2002/11/09
投稿数: 3
お住まい・勤務地: 東京都
投稿日時: 2002-11-09 15:57
ついに REST の記事が出たのであわてて @IT に登録してしまいました。

REST については主要な推進者である Roy Fielding (RoyF) と Paul Prescod (PaulP)のウェブページより辿れますが、

- http://conveyor.com/RESTwiki/moin.cgi
- http://www.prescod.net/rest/rest_vs_soap_overview
- http://www.ics.uci.edu/~fielding/pubs/dissertation/top.htm

が必読です。RoyF は HTTP/1.1 の設計などで得られた経験をベースとしてウェブのアーキテクチャモデル、ひいてはインターネットスケールで機能する情報空間のモデルを REST として概念化し、PaulP がそれをベースに現状の SOAP/XML-RPC（および他の RPC/OOP over network
プログラミングモデル）はウェブサービスの基盤として機能せず、REST を考慮した RESTful Webservice として規格を見なおすべきである、との主張を推進しています。

RESTはアーキテクチャモデルなので SOAP/XML-RPC と直接比較できないのですが、論点はこれら規格が REST の要件である

- 統一された名前空間による任意アプリケーション間の連携可能性
- 直行性の高い、少数の標準命令セットによる高い互換性
- 自己完結性の高いメッセージの交換によるステートレス性
-- これより得られる高いスケーラビリティ
-- これより得られる仲介サーバー等の第三者サービスの自由な介在
- いかなるデータも運搬できる、データモデルに関するポリシーフリー性

に違反しているため、通常の RPC/OOP パラダイムを REST の代表的モデルであるウェブにそのまま持ち込んでも機能しない、もしくはベースであるウェブに内在する発展性に遠く及ばず "Web Service" として不適当である、というものです。

この視点で SOAP/XML-RPC を見ると、これらはアプリケーションプロトコルを容易に（ウェブサービスとして）作成できるメタプロトコルであり、これ自体は問題ないものの、この結果

- エンドポイントありきのモデルではその先の名前空間が　URI 名前空間の外側におかれてしまう
- 実質的に別個のアプリケーションプロトコルが乱立し、任意のアプリケーション間の連携が阻害される

と指摘されています。

たまに REST は HTTP 濫用論と捉えられることがありますが、これは現状では REST 要件を満たす仕様の代表が HTTP およびその拡張モデル（WebDAV）だと考えられているためです。実際、HTTP/1.1 の策定時には REST という名前は存在しませんでしたが、ウェブのアーキテクチャモデルとして上記の要件を念頭に置きつつ命令セットの整備やプロキシとの協調のための仕様が決定されています。

現時点での REST の課題は

- ツールキットおよび適合するプログラミングモデルの提出
- コンセンサスとしての標準データモデル（構造化データ）の規定

だと思われます。RESTful WebService ではオブジェクト＝リソースなので従来の固定エンドポイントを相手にしたプログラミングではなく、エンドポイントが操作対象によって変動します（ハイパーテキスト空間＝アプリケーションステートという形なので）。このあたりの詳細はツールキットによってカバーされるはずですが、そのツールキットが現段階ではあまり（全然？）存在しません。もちろんウェブとの適合性が極めて高いので既存ツールは全て利用可能ですが、アプリケーション開発用のツールとして SOAP/XML-RPC のそれに近いものが望まれます。

もう一つのデータモデルについては、REST はアーキテクチャモデルであって仕様ではないため、XML-RPC の制限があるものの単純明快なデータモデルや SOAP のSOAP encoding のようなデータモデルを規定していません。このため document/literal なモデルになってしまいますが、できれば何らかの純粋にデータモデル交換に絞ったデータモデルも追加して欲しいところです。一応 SOAP encoding + REST という案は出ていますが、ツールキット実装がまだないので事実上待ち状態です。

とりえあず、FYI ということで投稿させていただきました。



[ メッセージ編集済み 編集者: tai 編集日時 2002-11-09 16:39 ]
tai
会議室デビュー日: 2002/11/09
投稿数: 3
お住まい・勤務地: 東京都
投稿日時: 2002-11-10 08:40
最初のコメントから外れて記事の内容にコメントすると Amazon の検索の
問題は本来 URI で参照可能（よって GET など各種の URI ベースの機能が
適用可能）とするのが適当な情報を POST の濫用で参照不能にしているからで、
これは REST とも関連はしますが、基本的には先に biac さんが書かれたように

- http://www.w3.org/DesignIssues/Axioms
- http://www.w3.org/Provider/Style/Input
- http://www.w3.org/TR/html4/interact/forms.html#h-17.13

の話だと思います。

面白いことに、Amazon.com が別途提供している API は RESTful で、
通常のウェブの枠内で（GET/POST 誤用もなく）XML Web Service が提供されて
います。これと対照的なのが Google で、こちらは通常のウェブ検索は RESTful
ですが、Google API は unRESTful になってしまいました。難しい…
1|2 次のページへ»

スキルアップ／キャリアアップ（JOB@IT）