RESTのインピーダンスミスマッチ非実在naka aki @naka_aki_spl やっぱりRESTとかいってる人らはGUIから背を向けるんだろうか？静的な見た目はいくらでもGUIに近づけられるけど、リソースやURLとの絡みを考えると普通のGUIのものすごく小さな「サブセット」になる感じ。 2010-04-13 10:34:35
動画で配信！「現場で使えるREST」鼎談 記事一覧 | gihyo.jp
第12回おわりに：RESTがつくる明るい未来 山本陽平，羽生章洋，和田卓人 2008-01-28
RESTを採用する理由があるとすれば - 第３回RESTful読書会 - 木曜不足
ちょっとだいぶ遅くなったが、第３回RESTful読書会について書いてみる。 ６章 読み取り/書き込み可能なリソース指向サービスの設計 @brownian さん担当。 ５章で途中まで、RESTとして迷いなく進めるところまで設計した地図サービスを、「細かいところに目をつむって」一応完成してみたという内容。 ７章 サービスの実装 @setoazusa さん担当。発表資料。 ブックマークサービスを Rails を用いて RESTful に実装してみたという内容。なぜ５・６章で設計した地図サービスを実装しなかったのかは謎。 この後８章が控えているからか、このあたりまで突っ込みおとなしめ…… ８章 RESTとROAのベストプラクティス RESTful Oriented Architecture のまとめと「ベストプラクティス」を紹介する内容。 id:ZIGOROu の資料は要所要所で本の内容に対する補
RESTful Web サービス読書会の資料公開 - 日向夏特殊応援部隊
http://text.art-code.org/presen/restfulreading/ 取り急ぎ資料だけうｐしまーす。感想はまた後日＞＜ でも一言だけ言えば、みんなデレっぷりが酷い件。
第3回RESTful本読書会に参加した - 岩本隆史の日記帳（アーカイブ）
第1回から参加していますが、今回が一番濃かったかも（特に懇親会が）。 http://kunit.jp/restful/wiki/index.php?%C2%E83%B2%F3%C6%C9%BD%F1%B2%F1 感想というか、色々思うところがあったのでメモ。 ブックマークリソースのURI問題 「7.3.3 ブックマークコントローラ」において、ブックマークがユーザーアカウントの従属リソースとなっていることに対し、id:n_shuyoさんが異議を唱えられた。私も、自分が実装するなら、ユーザーの従属リソースにはしないなあ。 というか、まず「例7-1」のDB設計がおかしくないか。私なら下記のようにする。 users user_id, name, full_name, email, password uris uri_id, uri, uri_hash bookmarks bookmark_id,
ウノウラボ Unoh Labs: Web APIとしてのWebDAV
komagataです。 社内の勉強会でWebDAVについて発表したので資料を公開します。 （この資料は少し言い過ぎなので２割増しで聞いといて下さい） [<< Prev Next >>] WebDAV.pdf(741KB)
RESTfulなWebサービスは、WebAPIを提供していないのか - winplusの日記
masuidrive on rails さんの記事で、RESTに関して疑問をもたれているものがありました。何が問題なのかうまく理解できていませんので、まったく勘違いしているかもしれませんが、RESTful Webサービスを読んできての練習問題として。 まずレスポンスコードでステータスを判断するとFreeSpotとかで問題にならない？ – @masuidrive blogから。 Railsだけを考えるなら、サービス全体をRESTfulにして、HTML以外にXMLも返す様にしておけば、外部から使うのも比較的容易......ただ、Rails以外でクライアントを作るのがメンドクサイ。 WEBサービスとはプラグラムが利用するわけで、当然そのクライアント・プラグラムを作成する必要があるということ。で、そのクライアント・プラグラムは、WEBサービスがどんなフレームワークで動作しているかとは（少なくとも原
REST思想とHTTPメソッドの関係 - プログラマの思索
RESTの基本的な発想は、HTTPメソッドでリソースをCRUDできるはずだ、というアイデア。 では、HTTPメソッドは、そもそもどんなものなのか？ 「安全なメソッドと冪等{idempotent} なメソッド」でいくつか語られている。 「RESTful Webサービス」で「べき等」という概念が出てくる。 「べき等」とは、同じ操作を何度行っても同じ結果であること。つまり副作用がなく安全であることを意味する。 少なくとも、GETはべき等に使うならば、安全であると言える。 しかし、GETで、リソースの削除や更新を行う時も、実はよくある。 REST思想に従うならば、GETは副作用を起こしてはいけない。 POST、PUT、DELETEがリソースの更新で副作用を起こすように使うべき。 RailsはREST思想を忠実に反映している。 また、Strutsも「http://～/***.do」というURLを見る
1
リリース、障害情報などのサービスのお知らせ
最新の人気エントリーの配信
j次のブックマーク
k前のブックマーク
lあとで読む
eコメント一覧を開く
oページを開く
