『Webを支える技術 -HTTP、URI、HTML、そしてREST』 第3部で、とくに面白かったところ。 ■HTTPの基本 HTTPの一番の特長はそのシンプルさです。 HTTPの重要な性質であるステートレス性 いわゆるwebサービスをつくる前に、これだけは知っていないと何もはじめられないことが実に簡潔にまとめてあります。ステートレスの利点と欠点（それとステートフルの利点と欠点）も分かりやすい。 ■HTTPメソッド たとえばログをリソースとして提供している場合は、ログに追記する操作はPOSTで行われるはずです。 たとえ「ログファイルへの追記」「ヒットカウンタの更新」が発生するとしても、GETは安全といえる。というのも、提供されているリソースは変更されていないから、という説明のあと、この文があって、すごく納得しました。 特別な理由がない限りは、リソースの作成はPOSTで行いURIもサーバ側で決
先日の記事に、ブックマークでコメントをいただいたので、少し。 # tkawa 「http://example.jp/users」もリソースになるね、とか考え始めたら「example.jp/users/」もリソースになるねというツッコミも可能。"/"にとらわれる必要もないし、提供しないなら403でいいと思う。パンくずリストはまた別の問題 まず、"/"付きのURLは想定外でした。コレクションのリソースを返す場合でも"/"なしのURLを使いそうだし、"/"付きのURLがリクエストされたら、403?404?にするのかな。それとも"/"なしにリダイレクトするか？ 『Webを支える技術』第2部に書いてあったらなあ、と責任逃れ。 id:tkawaさんのご指摘のとおり、想定されるすべてのリソースを提供すべきというのは無茶かもしれません。一方で、URLが（擬似的な？）階層構造になっているとすると、その途中も
『Webを支える技術 -HTTP、URI、HTML、そしてREST』 第2部で、とくに面白かったところ。 URIはWebサービスやWeb APIの設計において最も重視すべきパーツであると言えるでしょう。 ■クールなURI 変わらない シンプル 覚えやすい もちろんURIを変わりにくくする指針もまとめられている。 この「シンプル」「覚えやすい」というのは、「リソースのセマンティクスがパスの見た目で自明ならフラットなほうが好み。」というid:yoheiさんのコメントと、とうぜん一致している。で、たぶん難しいのは「自明」の基準。id:IwamotoTakashiさんは第15章に掲載されているURIの例を「自明」でないと感じておられるようだし、それは理解できる。少し冗長であっても記述的なURIの方にひかれる。 ■URIの不透明性 WebサービスやWeb APIをハックして情報を勝手に取り出したいと
id:IwamotoTakashiさんの問題提起「こんなURI設計、どう？ - 岩本隆史の日記帳（アーカイブ）」を読んで、少しだけ考えたこと。 コメントさせていただいたとおり、Rails流の「{データの種類}/{データのキー}」というURLには、そんなに抵抗はない。 しかし、Rails流でも、新規リソース作成用のリソース（たとえば登録用のフォームだとか）を「{モデル名}/new」からGETするというやりかたは、すこし微妙な感じがする。 GET http://rest.jp/users/123 => ID=123のユーザのリソース GET http://rest.jp/users/new => 新規ユーザ作成用のリソース どちらもユーザのリソースであるという意味では「自然な」URLだろう。ところが後者は、「新規ユーザ作成用のリソース」と「newというIDのユーザ」と両方にとることができる。も
4月7日 関西Javaエンジニアの会(関ジャバ) '10 4月度にいってきた。LTで「JAX-RS」と銘打って、中身はid:yoheiさんの『Webを支える技術 -HTTP、URI、HTML、そしてREST』の宣伝。 JAX-RS(LT)View more presentations from winplus. 興味をもってもらえたら、もうちょっと、ちゃんとJAX-RSを紹介しないと......。 ※お、一冊売れた。id:backpaper0さん、ありがとう。 ※発表の感想を忘れてました。簡単で、すみません。 ■Slim3 + GWT in Action(id:tan_go238さん) ・Slim3 全体はともかく、Slim3 Datastoreはいいかも。（JAX-RS推進派という立場なので。でも、GAEでJDOにこだわる必要はあるまい。） ・GWTはGWT-RPCなんですねえ（JAX-
『RESTful Java with JAX-RS』「Capter2:Designing RESTful Services」のメモに、はてなブックマークで、id:IwamotoTakashiさんから興味深いコメントをいただきました。 キャンセルはPOST（のオーバーロード）がしっくりくるなあ。もしくは /orders/{id}/canceled へのPUTかな。 短いコメントなので、ちょっと勝手に推測・補足させてもらいます。前者は親リソースへ数量がマイナスの注文をPOSTするという、いわゆる赤黒伝票の処理になるのでしょう。後者はキャンセル日とかキャンセル理由といった属性をもつリソースを作成するのでしょう。ということで、注文をキャンセルする４つの方法。 メソッド URI 表現 DELETE /orders/{id}?cancle=ture （なし） PUT /orders/{id} canc
※オライリーから翻訳書『JavaによるRESTfulシステム構築』が出ましたので、そちらを参照してください。以下の記事はアテになりません。 以下『RESTful Java with JAX-RS』「Capter2:Designing RESTful Services」のメモ。目次はこちら この章では、簡単な注文入力サービスのRESTfulなインターフェイスを定義する。 オブジェクト・モデルからはじめて、まずURIを決め（アドレス可能性を満たす）、次にデータフォーマットを決め（表現指向）、最後にそれぞれのURIでどのHTTPメソッドを許可するかを決める（統一インターフェイス）。 ■オブジェクト・モデル 注文は特定の顧客に関連づけられ、いくつかの項目で構成される。項目は購入された商品の型と数量を表す。 モデルは、Order, Customer, LineItem, Product。どのモデルも
※オライリーから翻訳書『JavaによるRESTfulシステム構築』が出ましたので、そちらを参照してください。以下の記事はアテになりません。 以下『RESTful Java with JAX-RS』「Capter1:Introduction to REST」のメモ。目次はこちら WWWは生活に欠かすことのできない一部分になっている。 でも、Webがうまくいっているのはなぜ？これほど巨大に成長できたのは？これだけ急速に拡がったのは？ Roy Fielding がこれらの疑問に答える形で、アーキテクチャの原則を特定した。これが REpresentational State Transfar(REST)。RESTの原則は以下のとおり。 到達可能なリソース RESTでは、情報（データ）のキーはリソースであり、すべてのリソースはURIで到達可能でなければならない。 統一され制約されたインターフェイス
「CRUD型RESTの欠点」として挙げられている以下の点。 外部に見せているのは内部的なデータベース構造ないしデータであって、考え抜かれた契約ではありません。 本当のサービスを迂回して直接データにアクセスすることを助長します。 CRUDはRESTにとって良くないのか？ テーブルを知らないとSQLは使えない訳で、それをそのままマッピングするのはテーブルを公開しているのと同じ。これを利用するには、クライアント側が、すべてのビジネスロジックを把握する必要がある。 羊の皮をかぶったクライアント−サーバでしかありません。 CRUDはRESTにとって良くないのか？ 確かにね。 ちゃんとしたRESTfulなWebサービスであれば、クライアント側は一切のビジネスロジックを把握する必要がなくなると。そうであれば、必要かつ十分なWebサービスは、すべてハイパーリンクで提供される。つまり、クライアントがハイパー
1
リリース、障害情報などのサービスのお知らせ
最新の人気エントリーの配信
j次のブックマーク
k前のブックマーク
lあとで読む
eコメント一覧を開く
oページを開く
