2009年12月16日「チュートリアルを少し変更、おバカな設定例」 Catyでは、ファイル名拡張子の意味付けや扱い方がデスクトップと同じなんだけど、「クールなURIは、拡張子がねーんだぞ」とか言われそうだから、そのうちラショネールを書かなきゃ。 「ラショネール」なんて奇妙な言葉が出てきてますが、目論見や主張が正当であることを示す根拠、てな意味ですかね＞ラショネール。 僕とKuwataさんが開発しているWebフレームワークCatyは、URLに、.html, .cgi などの拡張子を必ず要求します。クエリパラメータも遠慮なしに使います。「拡張子とかクエリパラメータなんて、RESTfulじゃないなー、クールじゃないなー」とか言う人がいますが、なにゆえに「拡張子やクエリパラメータがダメなのか？」 -- その根拠を示して欲しいもんです。僕らが積極的に拡張子やクエリパラメータを使う事情と根拠は、このエ
（[追記 date="翌日"]文言を少し改善し、注意を付け足したりしました。[/追記]） HTTPメソッド、URL、動詞（verb）に関して次の記事を書きました。 HTTPメソッドの正統的使い方と現実的対処法 HTTPメソッド、URL、そして標準化された動詞 訂正補足：HTTPメソッド、URL、そして標準化された動詞 問題点がほぼ明らかになり、全体の状況も見えてきたので、総括したいと思います。これで決定版にしたいのですが、実のところ、まだ考えが変わる可能性は否定できません。現時点では、以下に記述する案が最善だと思っていますがね。 内容： 用語の注意 事の発端，事の成り行き URLの意味と用途を分類する リソース種別ごとに動詞を考える さらにリソース種別ごとに動詞を考える GETに乗せるか、POSTに乗せるか インターフェースとしてのリソース種別と動詞 リソースとクラス 用語の注意 HTTP
Introduction There is new exciting technology that enables you to enhance and control Web pags that you visit (Greasemonkey, Firefox Add-ons) and run specific desktop experiences (Adobe AIR, Appcelerator Titanium, Fluid, Mozilla Prism). How do you find out if these exist? Currently, you have to search around to find them, but what if the site told you? This is where App Discover comes from. With t
[追記]「訂正補足：HTTPメソッド、URL、そして標準化された動詞」、「そろそろ決着、HTTPメソッド、URL、そして標準化された動詞」を書きましたので、あわせてお読みください。[/追記] 「HTTPメソッドの正統的使い方と現実的対処法」において、HTTPメソッドの本来の意味と、その本来の意味を損なわずにブラウザからリクエストする方法を述べました。最近また、Catyとの関係で、HTTPメソッドとURLをどう使うのが望ましいのか？ という問題を考えました。 HTTPメソッドには、GET, PUT, DELETE, HEAD, POST がありますが、ブラウザから発行できるメソッドはGETとPOSTだけです。「HTTPメソッドの正統的使い方と現実的対処法」において、GET/POSTを使って他のメソッド（PUT, DELETE, HEAD）を表現するために、_methodというクエリパラメータ
In this interview, Elliotte Rusty Harold discusses the true meaning of PUT and DELETE. In "Why REST Failed", Elliotte Rusty Harold described the difference between the four HTTP verbs GET, POST, PUT, and DELETE, and praised their virtues: The beauty of REST is that those four verbs are all you need. Everything you need to do can be done with GET, PUT, POST, and DELETE. You don't need to invent a n
Darrel Miller: Was the idea to call the REST workshop WS-REST designed to be as inflammatory as possible? http://www.ws-rest.org [via Don Box] Oh, cool, a conference with a topic I’m interested in in my back yard! It’s a shame it is too late to submit a talk proposal. Guess I’ll get to enjoy it as a civilian.
普段仕事でRails を使っている身ですが、Rails 2.x 系を使っているものが1つもない。結構前からRails 3 の話題がでてきている今、そろそろRails 2.x をまともに使っておきたいと思ったので、まずはREST について調べました。最初にREST について調べたのは、REST がRails 2.x (実際には1.2.x から)で導入された最も大きな概念だからです。 REST とは REST とはアーキテクチャスタイルである アーキテクチャスタイルとはデザインパターンのようなもので、システムを設計する上での方針をまとめたものである。 REST は「REpresentational State Transfer」の略である 直訳すると、「(リソースの)表現可能な状態の転送」。あるリソースの状態を表現したものがサーバからクライアントに転送されるのがREST。ここにでてきた「リソー
最近、増井君と私でアーキテクチャの話をすることが多いのだが、そんなディスカッションの中で気に入っているのは左の図のようなアーキテクチャ。 もちろん、核となるのはビジネスロジックを含んだModelの部分。そこをしっかりと実装し、内部構造を隠す粒度の荒いインターフェイスを定義し、外から何をされてもデータの整合性が壊れない様にすることは何よりも大切。 そして、そのModel層へのインターフェイスを特定の言語に依存したクラスやAPIではなく、HTTP上でJSON（XMLでもかまわない）をやりとりするだけの RESTfulなWeb Serviceにすることがミソ。こうすることによりにより、どんなに締め切りに負われようが、誰がControllerを実装しようが「ずるができない」ように作っておく（ずる＝本来使うべき外部インターフェイスだけでなく、Model内部に直接アクセスして依存関係を作ってしまう事）
原文(投稿日：2009/7/8)へのリンク Tim Bray氏は新しい投稿遅いRESTのなかでこの問題に答えようとしている： RESTfulなやり取りで、状態を変更する操作（POST、PUT、DELETE）が予測できないような多大な遅延時間を伴うとき、どう扱ったらいいのでしょう？ 氏は３つの異なる方法を説明している。これらの方法はKenaiプロジェクトの「非同期処理要求の扱い方」という提案に対して、提示されたものだ。以下の方法が含まれている: リソースを基にした方法。この方法は 新しく"状態"を表すリソースを使います。このリソースは以下のフィールドを保持します。: "uri" - クライアントが処理完了を問い合わせるためにGETすることができるURI。受信された各非同期処理は状態を表すユニークなURIを与えられています。このため、複数の処理を起動し、一度に追跡できます。 "status"
前回の記事「RESTクライアントが知っているべきこと」に、id:nsiena さんからトラックバックをいただきました。 RESTful API の後方互換性 - Siena.の日記 斜め上の応答になってしまうかもしれませんが、思ったことを書いてみます。 API変更の性格分類とサーバがとりうる対策 まず、APIがどのように変更されるか分類し、サーバが取りうる対策をまとめてみましょう。 API変更の性格 サーバがとりうる対策（概要のみ） リソースのURIが変わる ステータスコードで「301 Moved Permanently」を返し、Locationヘッダで新規URIを返す。 リソースのメディアタイプが変わる Content-Typeヘッダで適切なメディアタイプを返す。リクエストのAcceptヘッダによっては、ステータスコードで「406 Not Acceptable」を返さなければならないかも
RESTfulは一昨年くらいから出てきた技術的な用語だが、一般的なシステム開発においてどのようなメリットがあるだろうか。まず第一にデータベースとアプリケーションサーバを切り離すことができる。いわゆるデータとシステムの疎結合だ。 デモアプリケーション 第二にアプリケーションのインタフェースに様々な選択肢が増えるようになる。Webシステムに限らずiPhoneやコマンドラインでの操作も容易だ。そしてデータの置き場所も制限がなくなるのだ。そう、その夢を感じさせてくれるのがApp Engine Rest Serverだ。 今回紹介するオープンソース・ソフトウェアはApp Engine Rest Server、Google App Engine（GAE）をRESTfulサーバにするソフトウェアだ。 GAEをRESTfulに対応したサーバにするとどうなるか。それは無制限とも言えるストレージをHTTPベー
Diagram An activity diagram to describe the resolution of HTTP response status codes, given various headers. The diagram is available in various formats: http-headers-status.gif (205 kb) http-headers-status.jpg (340 kb) http-headers-status.png (447 kb) http-headers-status.svg (315 kb) please see request for assistance below The Visio diagram, published on Google Code Request for assistance
「コマンド的な処理をどうやってRESTfulに実装するか」に書いた内容を敷衍します。 SunのクラウドサービスAPI 先日、Sun MicrosystemsがSun Cloudというクラウドサービスを提供すると発表しました。 米Sun、Amazon対抗のクラウドサービス「Sun Cloud」を発表 - SourceForge.JP Magazine この記事には、クラウド操作用APIがRESTベースで提供される予定であることも書かれています。 Sunは開発者向けにクラウドAPI「Sun Open Cloud API」を提供する。RESTベースのAPIで、CreativeCommonsライセンスの下でリリースするため、開発者はSun Cloudと相互運用性のあるクラウドを構築できるという。 そのAPI仕様のドラフトが「The APIs for the Sun Cloud: Wiki: Hom
美しいWebサービス設計に欠かせない思想として注目されている「REST（Representational State Transfer）」。HTTPプロトコルに「リソース指向アーキテクチャ」という考え方を導入し、「なんでもRESTで表現できる」として熱心にこの思想の普及につとめている人々は「RESTafarians」＝REST信者として尊敬を集めているが、いま彼らが分裂の危機に瀕している。REST論壇を真っ二つに分ける激論が勃発したのだ。議論の火種となったのは 「恋愛は“GET”で表すべきか、“PUT”で表すべきか」 というもの。 リソースへのアクセスメソッドをGETにするかPUTにするかは、REST信者にとっては美しいWebサービスを設計するうえでもっとも重要な問題だ。ここで「恋愛はGET」と主張して譲らないのが、業界でRESTエヴェンジェリストとして知られる株式会社リコーの山本陽平氏。
DeWitt: @dehora Sorry, that should read: We haven't created an AtomPub *for* RPC yet. IMHO, that's the biggest gap today. What we seem to need is a data-oriented REST protocol. We already have document-oriented REST protocols covered with the Atom Publishing Protocol, but what if the information you want to convey is data, i.e. doesn't have the minimum meta-data to qualify as a document, such as a
1
リリース、障害情報などのサービスのお知らせ
最新の人気エントリーの配信
j次のブックマーク
k前のブックマーク
lあとで読む
eコメント一覧を開く
oページを開く
