今日は第３回 RESTful 読書会だった。主催の id:kunit さん＆nsiena さん、担当の方々、参加者の皆さんお疲れ様でした〜。 読書会の模様（特に８章の DIS られっぷり）はまた今度まとめるとして。 この前 URI Templates ( http://bitworking.org/projects/URI-Templates/ ) の各言語の実装を調べたよと読書会で話したら、id:t-wada さんに「調査結果が addressable になるといいなーw」とリクエストされたので、早速宿題をやっつけておく。 URI Templates の実装一覧 本家 (experimental implementation in Python、 59:04+09:00">draft-03相当):http://code.google.com/p/uri-templates/ Ruby -
みんな REST 好きなんですねぇと言うのが良く分かった第3回の読書会。僕の方は前日夜からプレゼンを書き出して、自分が発表する10分前にやっと完成したと言う体たらくぶり＞＜ 8.8節に関して キュー、一括処理、トランザクションなどの考え方の例が示されている8章でも最も突っ込みどころの多い所。リソースの適用する考え方としては十分楽しいけど、だいぶ無理してるのでこれはベストプラクティスと呼ぶには筆者の信念に偏り過ぎてると思った。 また一括処理の指定の際に例えば、/resource1, /resource2/subres1 みたいな二つのリソースに対して統一インターフェースで何かする場合、/sets/resouce1;resouce2/subres1 のように指定するんだけど、これってURI Template を使えば、その記述の仕方で対象となるリソースを指定する事が出来るから SQL で言う所
RESTful なアプリケーションでは、対象とするリソースに副作用を及ぼすときは POST なり PUT を使うのがベストプラクティス。(ベストプラクティスという言葉を使ってみたかった!) この考え方はウェブアプリケーションを作るときに、GET にするか POST にするかに明確な指針を与えてくれてすっきりします。 で、ふと思ったんだけど、表面的には GET でよさそうだけども実は中でリソースに副作用が及んでいるような代物はどうしたらいいんだろうなということ。例えば検索エンジンなんかで、クリックに合わせて後ろでクリック回数を数えてたり統計とってたりするものがあると思うんだけど、そういう類。 ウェブサイトの検索エンジンとかだとクリック対象の URI が差すリソースが外部サイトでちょっとイメージしづらいので、例えば search.cpan.org など。モジュールの検索結果からのクリック回数を
yohei-y:weblog: REST 入門
日本語の REST のリソース集を以前作ったのだが、 日本語では一般人向けの解説がない。 sheepman 氏の REST のページはすばらしいんだけど、多少わかっている人向けだ。 市山氏のプレゼン資料は RoyF の論文を詳しく解説していてよいのだけれど、いかんせんアカデミックすぎる。 技術的な要素も抑えつつ、入門者にもわかりやすい解説はないものかと探していたのだが、みつからない。 英語の文書を訳すことも考えたんだけど、あまりよいものが見つからない。 で、結局自分で書くことにした。 最初はひとつのポストで済ませるつもりだったんだけど、書き始めたら長くなってしまったので、複数のポストに分けることにした。 えらそうなことを書いたが、内容は「ないよりマシ」といったレベルだろう。 前書きが長くなったけど(ここから始まりです。ですます調なのは入門記事だから)、 この記事(から始まる一連のポスト)は
2006年04月22日20:50 カテゴリWEB+DB PRESSiTech RESTは簡単なんだけど... というわけで早速質問です。 WEB+DB PRESS yohei-y:weblog: WEB+DB PRESS Vol.32 に REST の記事を書きましたただ、やっぱり REST は難しいですね。人に説明するたびに思います。記事でわからないことがあれば、ここにコメントしていただければできる範囲で返答しようと思います。なぜAtomPPでは、記事の新規作成がPOSTで、更新がPUTなのでしょう。 WebDAVやFTPといったファイル操作系のProtocolでは、PUTはコンテントをアップロードするためのコマンドです。それとの整合性を考えたら、コンテントの新規作成をPUTでやって悪いわけというのが思いつきません。 あるいは、URIの名前を、Clientの意向で決める場合(例えばアップ
指定されたURLは存在しません。 URLが正しく入力されていないか、このページが削除された可能性があります。
前回，REST（REpresentational State Transfer）アーキテクチャ・スタイルに準拠した，新しい軽量なWebサービスが増えてきたことについて触れました。アーキテクチャ・スタイルとは，情報システムのプロトコルやデータ構造（情報構造）の基本的性質を規定する“制約の束”のようなものです。今回は，このRESTについてもう少し説明しましょう。 RESTを既定する制約を挙げると以下のようになります。 (1)クライアント/サーバー型 (2)ステートレス（Stateless） (3)キャッシュを許可 (4)統一インターフェース（Uniform Interface） (5)階層化システム（Layered System） (6)コード・オン・デマンド（Code-on-Demand） (1)は，WebブラウザとWebサーバーで構成される，クライアント/サーバー型のネットワーク・アーキテ
See related links to what you are looking for.
yohei-y:weblog: REST ってやっぱり難しいかも。
前のエントリでこんなことを書いたばかりだけれど、REST ってやっぱりどうよ、という気分になったので久々に blog を更新してみる。 ただただしさんのおれだったらフォト蔵APIをこうするを読んで、僕が del.icio.us に書いた感想は +1。ID == URI ですよね。Cool URI は名詞であるべき、というのは強調したい。「日本REST協会」入りたくないなー(笑)。みんな休んでそう というもの。たださんのエントリでは URI と書くべきところが ID になっててちょっと気になったり、「作法」は「アーキテクチャ」じゃなくて「アーキテクチャスタイル」だ、とか思ったのだけれど、でも本筋としては納得の内容だった。 しかし、たださんのエントリの、たかはしさんや mizzy さんのコメントを読んでうーんと唸ってしまった。 僕にはお二人の言いたいことがわかる。んで両方間違っていないと思う。
« AJAXが大事何ではないはず | メイン | "Crossbow", Windows Forms & WPF Interoperability » 2006年02月18日 SOAP vs REST？ いいから出荷しろ Pragmatics - Don Box's Spoutlet ドン箱先生が、あんまりSOAPとRESTの違いについてあまりにも聞かれてウザイからと、その違いを5項目にまとめている。 SOAPを使用しているのか、POX（Plain Old XML)を使用しているのか。 一つはそれらのフォーマットにXML Schemaを使用しているか。 一つはXML Schemaを静的に言語にバインディングしているか。 一つがHTTPに特有の特徴に依存する程度。それは語られているように、危険覚悟でGETにねじどめする。 一つはメッセージ中心の設計アプローチをと
Someone recently asked me about how to handle an internal product debate around REST vs. SOAP. In hopes I never have to address this debate again, here's a record of what I told them. Don Box が REST vs SOAP についての Pragmatics について語っている、という記事。この記事を読む前に OPC Diary: SOAP vs REST？ いいから出荷しろ という記事をコメントまで含めて読んでおくと良い感じで消化できる、と思います。 で、あんまり記事とは関係ないお話で。POX - Plain Old XML という単語を恥ずかしながら初めて聞いたもので、そこに反応。 Plain Old
Ajaxについていろんな話を調べたり聞いた中でも、興味深かったのはRESTとの関係でした。簡単にいえば、AjaxとRESTは両方ともWeb2.0の構成要素として挙げられていながら、実は相反したものである、というパラドックス的な関係です。 RESTとは「REpresentational State Transfer」の略で、詳しくは＠ITの記事「Webの「正しい」アーキテクチャ」記事を読んでいただいたり、さらに詳しくは山本陽平氏の「REST入門」あたりをぜひ読んでいただきたいのですが、ひとまずRESTをものすごく乱暴に書いてしまうと、“Webアプリケーションであれば、状態やリソースごとに異なるURLを持とう”といったアーキテクチャのことだと私は考えています。 例えば、“住所を入力する”ためのWebアプリケーションがあったとしたら、入力画面→確認画面→確定画面という画面遷移が考えられます。この
ブラウザとWebサーバの組み合わせで作られる、いわゆるWebアプリケーションの開発が盛んだ。それまでのクライアント／サーバ・システムにおいて悩みの種だった新バージョンの配布や保守の問題が解決され、システム管理者が楽になったのが理由であるといわれている。しかし、クライアント／サーバ・システムを開発していた開発者にとっては、Webは非常にシステムを作りにくい環境だった。貧弱な機能しか持たないブラウザと、単純なデータしか送信できないプロトコルを利用して、これまでどおりのLook and Feelのアプリケーションを作れというのだ。どだい無理な話である。 だが、開発者には味方がいた。開発ツール・ベンダである。開発ツール・ベンダは、Webアプリケーション開発者が悩んでいるのをビジネス・チャンスと考えた。その結果、さまざまなWebアプリケーションの開発環境が作られた。それらすべての開発環境に共通してい
1
リリース、障害情報などのサービスのお知らせ
最新の人気エントリーの配信
j次のブックマーク
k前のブックマーク
lあとで読む
eコメント一覧を開く
oページを開く
