RailsにおけるRESTfulなURL設計勉強会 つぶやきのまとめ。 千駄ヶ谷.rbなのに渋谷にあるミクシィで行いました。
RailsにおけるRESTfulなURL設計勉強会 千駄ヶ谷.rb #12 #sendagayarb
RailsにおけるRESTfulなURL設計勉強会 つぶやきのまとめ。 千駄ヶ谷.rbなのに渋谷にあるミクシィで行いました。
Rails-resource-routing-design-bootstrap(ja)
Sendagaya.rb#12での講演資料に口頭のまとめを追記したものです。
HTTP メソッドとリダイレクト ステータス コード
HTTP Methods and Redirect Status Codes http://blogs.msdn.com/b/ieinternals/archive/2011/08/19/understanding-the-impact-of-redirect-response-status-codes-on-http-methods-like-head-get-post-and-delete.aspx 更新間隔が開いてしまいましたが、今回も EricLaw’s IEInternals の記事をを私訳しました。 HTTP レスポンスでクライアントがリダイレクトされる際の挙動について、RFC の記述とブラウザーの実装の微妙な違い、またブラウザー間の挙動の相違について興味深い情報が示されています。 以下の文章は EricLaw’s IEInternals の 8/19 の記事 HTTP Met
danwebb.net - It's About The Hashbangs
28 MAY Before I get started here’s the disclaimer: The opinions expressed in this rant are my own personal opinions on web development and do not represent the views of my employer, its engineering organisation or any other employees. A few months back there was a flurry of blog posts and conversations over Twitter both for and against the now fairly common practice of using hashbang urls (example
Hashbang(#!)なURLの恐怖
諸方面からお叱りの言葉しかいただけない#!なURLは様々な問題をはらんでいますが、来るべき未来(もうすぐですよ！)におけるメンテナンス性という問題についてAdactioで取り上げられていました。#!の表面的な凶悪さに思考停止していて、こういった本質的な問題についてはまったく考えていなかった気がします。 その問題というのは、#!なURLからHistory APIなどを利用してクリーンなURLに乗り換えよう(戻そう)としても、古い#!なURLを有効なままにするためにはサーバー側の何か(単純なリダイレクトやmod_rewriteなど)ではどうしようもないので、クライアント側での(JavaScriptを利用した)リダイレクトを提供する機能を提供し続けなければならないというメンテナンス性の悪さです。 この#!なURLのメンテナンス性の悪さという問題は、URLの#以降はクライアント側の扱いなので、クラ
RailsでのfavoriteのURL設計 - ぶろぐ。@はてな
http://d.hatena.ne.jp/r7kamura/20110505/1304577667がすごいなと思って、routes.rbの書き方の例についてコメントしたのですが、自分で書いておいて後で「unfavorite」はちょっとまずいかなと思ったので、favorite（いわゆるお気に入り、スター）はどういうふうに設計すればいいのか考えてみました。 構造はよくある感じの、 tweet has_many favorites user has_many favorites 任意のツイートに任意のユーザーがお気に入りをつけられるというもの。別にツイートじゃなくても何でもOKです。 ブログのコメントにはこのように書きました。 (1) resources :tweets do member do post 'favorite' post 'unfavorite' end end ルーティングは
さらなる「#!」URL批判 - karasuyamatenguの日記
このブログはlifehackerを含むgawkerメディア系サイトの#!URLへの移行を批判している。 http://isolani.co.uk/blog/javascript/BreakingTheWebWithHashBangs/ 以下、isolaniとテングの見解をごっちゃ混ぜに紹介する。 lifehacker他のgawkerメディアサイトが数日前に長時間におよびアクセス不能になった。(厳密に言うとページ内のコンテンツアクセス不能になった) #!URLベースのサイトはJavaScriptにエラーがあるとコンテンツが一切ロードせずのっぺらぼう状態になってしまうようだ。 #!について 「#!」は何で呼ぶの？ shebangと綴られる。 Hash=# Bang=!の略 発音すると「シバン」といったところか。(ちなみにUnixの#!とは無関係) 以下「#URL」は： サイト内のロケーション情
URL Design — Warpspire
December 28, 2010 URL Design You should take time to design your URL structure. If there’s one thing I hope you remember after reading this article it’s to take time to design your URL structure. Don’t leave it up to your framework. Don’t leave it up to chance. Think about it and craft an experience. URL Design is a complex subject. I can’t say there are any “right” solutions — it’s much like the
時代はRESTへ。SOAPの終わりを象徴する、Webサービス標準化団体のWS-Iが活動終了
SOAP、WSDL、UDDIなどを基盤とするWebサービスの標準化を行ってきた団体WS-I（Web Services Interoperability Organization）が、2002年からの約8年間の活動に幕を下ろしたことを正式に発表しました（参考：WS-I Completes Web Services Interoperability Standards Work（pdf））。 WS-Iは、WS-*と総称されるWebサービスのさまざまなプロトコル策定に取り組んできましたが、複雑すぎるといった評判がつきまとい、また策定そのものにも予想以上の時間がかかったことなどで、当初の想定ほど普及に至りませんでした。 そのSOAPに代わり、ここ数年サービス間をつなぐAPIとして存在感が高まっているのがREST（Representational State Transfer）と呼ばれるアーキテクチ
Whatfettle - Paul Downey (psd)
At the XML Summer School, my marra Marc Hadley and I ran a short workshop on designing REST Webby services. We used pin-boards around the room, along with index cards: which we connected with ribbon to paper-prototype HTTP message flows: People seemed to like the cards, adopting them as labels: All was going well until someone slipped "204 - No Content" into my badge holder. This made me grumpy, b
エンタープライジーなREST - L'eclat des jours(2010-08-10)
_ エンタープライジーなREST オライリーから私が監訳（という作業を初めて経験したわけですが、それは別の物語）した、『JavaによるRESTfulシステム構築』という本が近々出ます。 JavaによるRESTfulシステム構築(Bill Burke) この本は、実にいろいろな面からおもしろい。おもしろいので、オライリーの編集の方に翻訳して出版する価値もあれば意義もあるとお勧めしたわけで、当然、読むことをお勧めします。 さて、何がおもしろいのか。一端は後書きに書いたけど、当然、書ききれない点や後書きに書いてもしょうがない点とかは省略しているので、そのあたりを含めて紹介します。 1. 著者がBill Burke これはおもしろい。というのは、BillはJBoss野郎なのだ。当然、CORBAからのORPC男。当然EJB。もちろんEJB3。 なぜ、そのBillが『JavaによるRESTfulシステ
第2回 REST侍は国益に殉ずる覚悟を持っていた | gihyo.jp
圏外からのWeb未来観測、2回目のゲストは『Webを支える技術』（注1）の著者の山本陽平さんです。山本さんは、クールでロジカルな話し方をする人で、一見、典型的な理系の技術者という印象なのですが、実は、すごく激しいパッションを秘めた人でした。技術的に正しい選択を通すためには会社を辞める覚悟までしていたそうです。現代に生きる侍の一人ではないかと思います。 『Webを支える技術』に入れなかったもの 中島：『Webを支える技術』は、もう定番の教科書としての評価が定まってますね。 山本：essaさんにもレビューしていただいて（【1】、【2】）ありがとうございます。 中島：何よりこの本は、話題の絞り込みが適切だと思うのですが、意識してカットしたところとかはあるのでしょうか？ 山本：まず、プログラミング言語に依存したくなかったので、具体的な言語のコードはほとんど入っていません。その代わりHTTPの生々
信頼できるメッセージングは、不要。
原文(投稿日：2010/06/18)へのリンク SOA やWeb サービスで一般的に容認された考え方は、信頼できるメッセージングの必要性である。信頼性のあるメッセージングとは、送信アプリケーションによって送られたメッセージは、もう一方で確かに、受信されそして１回のみ受信される、ことを保証する。RESTに対する最も共通の拒絶理由の１つは、RESTが信頼できるメッセージングを提供していないことである。Stefan Tilkov 氏が次のように書いている：「RESTful HTTPは、WS-ReliableMessaging と同等ではない、としばしば指摘され、このために、信頼性が争点（これは、相当変わってしまう。あらゆるシステムがビジネス シナリオによって、どのような関連性でも持つので）となる分野では、使えない、と多くの人々が結論している」[1]。もちろん、Tilkov氏は、これに賛成しないで
draft-gregorio-uritemplate-04 - URI Template
This is an older version of an Internet-Draft that was ultimately published as RFC 6570. Network Working Group J. Gregorio, Ed. Internet-Draft Google Intended status: Standards Track R. Fielding, Ed. Expires: September 9, 2010 Day Software M. Hadley, Ed. Oracle M. Nottingham, Ed. D. Orchard Mar 08, 2010 URI Template draft-gregorio-uritemplate-04 Abstract A URI Template is a compact sequence of cha
RESTが先か、Webが先か
𝘮𝘢𝘴𝘶𝘪 @masui 「RESTアーキテクチャのおかげでWebは成功した」という表現は正しいのだろうか? 「Webは成功した。Webの特徴はRESTという風に表現できる」ということはないのだろうか? 2010-05-08 23:20:45
Webを支える技術 -HTTP、URI、HTML、そしてREST (WEB+DB PRESS plus)(山本 陽平) - ただのにっき(2010-04-23)
■ Webを支える技術 -HTTP、URI、HTML、そしてREST (WEB+DB PRESS plus)(山本 陽平) 技術評論社の稲尾さんから献本いただいた。読むの遅くてすみません(ここまでテンプレ)。 とはいえ、すでに出回っている書評に付け加えることはほとんどないんだよなぁ。Webテクノロジーの基礎に関する最高の教科書のひとつだと思う。付録のリファレンスも含めて、作りが極めて教科書的で、色褪せない工夫が随所にあって感心する。Webサービス開発者に限らず、Webに携わる者はみんな読んでおくべき。 実は、途中までは、対象読者は開発者だろうと思っていたんだけど、最後のリソース設計のところで情報アーキテクチャとの関係が登場して、もっと広く読まれるべきだと思い直した。「Webアプリとか関係ないし」とか言いつつふつーの情報サイトを設計している人がいたら、自分が作ってるサイトが、いつかどこかでA
Kazuho@Cybozu Labs: REST におけるトランザクションについて (Re: Web を支える技術)
といいつつ、ひとつだけ理解できないというか、納得できないところが。トランザクションのところがなんだかRESTっぽくないのがすごく気になる Webを支える技術 -HTTP、URI、HTML、そしてREST (WEB+DB PRESSプラスシリーズ)(山本 陽平) - ただのにっき(2010-04-23) 「Web を支える技術」は自分もとてもいい本だと思う (教科書としてすばらしいし復習用としても読みやすいのでイイ) のですが、トランザクションの所だけは分かりづらいなと感じました。その原因は、atomic transaction で解決できる課題を例として使っているという点と、トランザクションと更新クエリのレイヤ分割がされていない、という２つの点によるものではないでしょうか。 HTTP 上でトランザクションを表現する必要があるケースのほとんどは、atomic transaction ではなく
リリース、障害情報などのサービスのお知らせ
最新の人気エントリーの配信
j次のブックマーク
k前のブックマーク
lあとで読む
eコメント一覧を開く
oページを開く
リソースモデリングパターンの提案 #sendagayarb
RESTful Web アプリの設計レビューの話
REST-Inspired SOA Design Patterns (and Anti-Patterns)