確認画面問題とリソースモデリング - 烏賊様
この条件での確認画面問題は，トランザクションリソースを導入しなくても，もっとシンプルに考えて解決できると思います． 処理内容：ユーザ名とパスワードが入力項目となるユーザ登録処理 画面遷移：登録画面→確認画面→結果画面 確認画面問題はトランザクションリソースの導入で解決できるのでは - 岩本隆史の日記帳（アーカイブ） まず上記の条件から次の事が言えると思います． ユーザ登録処理とはユーザリソースの作成処理と考えられる 画面はあくまでリソース状態が表示されるものなので，画面遷移とはユーザリソースの状態を都度表示しているもの ということで，あくまでユーザリソースとそれに対する CRUD（この場合は DELETE はないが）として考えればいいかな，と． まず最初の登録画面はユーザ作成フォームリソースを取得します． GET /users/new登録画面から確認画面のところはユーザリソースの新規作成と
確認画面問題はトランザクションリソースの導入で解決できるのでは - 岩本隆史の日記帳（アーカイブ）
REST勉強会、参加したかったなあ。知らなかった私が悪いんですが。 勉強会では「確認画面ってどう扱うの？」という議題が出たそうで、私なりに考えていた解をここに提示する次第です。 例示する処理 処理内容：ユーザ名とパスワードが入力項目となるユーザ登録処理 画面遷移：登録画面→確認画面→結果画面 1. トランザクションリソースの作成 クライアントは、登録画面から「トランザクションリソースのファクトリリソース」にユーザ名とパスワードをPOSTします（通信イメージは適当です）。 POST /newaccount-transactions HTTP/1.1 HOST: example.org username=iwamot password=hogehoge 妥当な入力なら、サーバはトランザクションリソースを作成し、そのURLを返します。これが確認画面となります。 HTTP/1.1 201 Crea
続・こんなURI 設計、どう？ - 岩本隆史の日記帳（アーカイブ）
先日書いた「こんなURI 設計、どう？」の続きです。 例：商品ブックマークサービス URI設計の例として、商品ブックマークサービスを対象に考えてみます。提供するおもなリソースは、以下の5つです。 リソース名 パンくずリストのイメージ トップレベルリソース トップ ユーザ登録画面リソース トップ＞ユーザ登録 ユーザ別ブックマークリソース トップ＞iwamotのブックマーク ブックマークリソース トップ＞iwamotのブックマーク＞Webを支える技術 商品リソース トップ＞Webを支える技術 うち商品リソースについては、はてなブックマークのエントリページ（例：http://b.hatena.ne.jp/entry/twitter.com/）みたいなものとお考えください。商品ブックマークサービスでは、entry以下のURI断片の代わりに、Amazonの商品コード（ASIN）を用いることにします。
こんなURI設計、どう？ - 岩本隆史の日記帳（アーカイブ）
先日書いたように、作りたいWebサービスがあります。当然ながら、まずは設計から始めなければなりません。 設計にあたっては『Webを支える技術』の第15章で紹介されているサービス設計手法を用いることに決めたのですが、URI設計のステップで、はたと考え込んでしまいました。 以下、第15章に掲載されているURI例で違和感の原因を探ってみます。 郵便番号リソースのURI http://zip.ricollab.jp/1120002これは違和感ありません。 検索結果リソースのURI http://zip.ricollab.jp/search?q=小石川ここで若干の違和感を覚えます。郵便番号データのキーである「1120002」と「search」が同列に並んでいるのが原因です。 いや、とくに気にする必要はないのかもしれません。「search」という郵便番号は今後も現れないでしょう。もし現れたとしても、ク
Kazuho@Cybozu Labs: REST におけるトランザクションについて (Re: Web を支える技術)
といいつつ、ひとつだけ理解できないというか、納得できないところが。トランザクションのところがなんだかRESTっぽくないのがすごく気になる Webを支える技術 -HTTP、URI、HTML、そしてREST (WEB+DB PRESSプラスシリーズ)(山本 陽平) - ただのにっき(2010-04-23) 「Web を支える技術」は自分もとてもいい本だと思う (教科書としてすばらしいし復習用としても読みやすいのでイイ) のですが、トランザクションの所だけは分かりづらいなと感じました。その原因は、atomic transaction で解決できる課題を例として使っているという点と、トランザクションと更新クエリのレイヤ分割がされていない、という２つの点によるものではないでしょうか。 HTTP 上でトランザクションを表現する必要があるケースのほとんどは、atomic transaction ではなく
InfoQ: REST成熟度モデルの３レベル
原文(投稿日：2010/03/24)へのリンク Martin Fowler氏は、新しい 論文 で、Leonard Richardson氏によって開発された RESTful成熟度の３レベルモデル を使って、 webスタイルのシステムを説明している。 Fowler氏によれば、成熟度モデルの開始点は、リモートなやりとりための純粋な通信システムとして、HTTP を使うことである。この場合、１つのサービスがある－予約サービス、これは１つのメソッドコール（彼の例では、POST）とXML入／出力を使って、特定のリクエストとリプライを交信する。 空いている医者に予約する場合には、リクエストが必要で： POST /appointmentService HTTP/1.1 <openSlotRequest date = "2010-01-04" doctor = "mjones"/> これにリプライを返す： H
1
リリース、障害情報などのサービスのお知らせ
最新の人気エントリーの配信
処理を実行中です
j次のブックマーク
k前のブックマーク
lあとで読む
eコメント一覧を開く
oページを開く
