非実在naka aki @naka_aki_spl やっぱりRESTとかいってる人らはGUIから背を向けるんだろうか?静的な見た目はいくらでもGUIに近づけられるけど、リソースやURLとの絡みを考えると普通のGUIのものすごく小さな「サブセット」になる感じ。 2010-04-13 10:34:35
えー、例によって固い話になるので、まずは、ガッキーの声で脳内再生してリラックスしてください。 Webはまだ〜♪じゅうろくだ〜から〜〜♪ 1994年に、ジム・クラークとMosaic開発者らによりモザイク・コミュニケーションズが設立されてから16年間、ブラウザから覗くことができるWebの世界は成熟してきた。 誰もがWebが何であるかわかった気になっているが、Webはまだ16才で、その本当の可能性はこれから花開く。 Webとはプロトコルの両側にある自由である。 コンピュータプログラムには無限の可能性があるが、無限の可能性を二つつなげても、そこには混乱しか生まれない。通信に意味を持たせる為には、決め事が必要である。 自由を生む為にはプロトコルが必要で、そのプロトコルはキツすぎてもユルすぎてもダメだ。奇跡的にちょうどいいゆるさのプロトコルが集まったものがWebだ。 Webを支える技術 -HTTP、U
steps toward the glory of REST A model (developed by Leonard Richardson) that breaks down the principal elements of a REST approach into three steps. These introduce resources, http verbs, and hypermedia controls. 18 March 2010 Recently I've been reading drafts of Rest In Practice: a book that a couple of my colleagues have been working on. Their aim is to explain how to use Restful web services t
このブログ、1年近くご無沙汰していました。その間なにをやっていたかというと、実はずっと本を書いていました。『Webを支える技術 ── HTTP、URI、HTML、そしてREST』というなんとも挑戦的な題名の本です。技術評論社さんのWEB+DB PRESS Plusシリーズの11冊目で、来月発売される予定です。 Webを支える技術 ── HTTP、URI、HTML、そしてREST山本 陽平技術評論社 2010-04-08 この本は、WEB+DB PRESSで連載していた「RESTレシピ」という連載がベースになっています。実は連載が1年経ったくらいから、技評さんからは書籍化のオファーをもらっていました。ただ、その時点では書いた分量も少ないし、そもそも自分に雑誌記事とは比べ物にならないくらい分量のある本が書けるとは思っていなかったので、書籍ではなく連載継続という形でトータル2年間連載をしました。
OOエンジニアの輪! 第 43 回 和田卓人 さんの巻 今回のゲストは、和田卓人 さんです。テスト駆動開発の紹介など様々な活動で知られています。 ■ はじめに --- まこたんさんとのつながりは たぶん arton さんがまこたんを紹介した絡みに似てるかもしれないんですけど、以前「Seasar のからさわぎ」とか、 Seasar*1 のコミュニティが、よく飲み会やってたんですね。初めて会ったのもたぶんこの辺りだったと思う。 --- 2005 年ぐらいですか… ヨーロッパ選手権が 2004 年だから…… 2004 年、 2005 年ぐらいですね。 僕はサッカーが好きなんですが、サッカーファンというものは 2 年単位で年を覚えていられるんです。 4 年単位でワールドカップがあって、さらにそこから 2 年ずれて 4 年単位でヨーロッパ選手権があるので、大体あの時に何やってたってのは 2 年刻みで
先日のQConで大場さんもおっしゃっていたことですが、Railsで開発をする上でものすごく重要なポイントに、Railsの敷いたレールから降りないというのがあります。別にコレはRailsが不自由だというわけでなく*1、通り一遍のものしかできないというわけでもなく、ただ基盤と相性の悪い設計すればあとで苦労するという、当然の話なわけです。 最近、私を含めいろいろな方が「レールから降りないで作るのが重要」と話しています。が。じゃあそのレールはどこにあるのかという話はあまり聞かれません。ということで、ふだん私がRailsアプリを設計するときに意識しているレールを言語化してみて、議論なりのたたき台にしたいな、と思った次第です。 とはいえDB周りは「羽生さんのERDレッスン嫁」で7割くらい済む話*2なので、まずはコントローラから。 設計指針としてのmap.resouces Rails 2.xにおいて、コ
美しいWebサービス設計に欠かせない思想として注目されている「REST(Representational State Transfer)」。HTTPプロトコルに「リソース指向アーキテクチャ」という考え方を導入し、「なんでもRESTで表現できる」として熱心にこの思想の普及につとめている人々は「RESTafarians」=REST信者として尊敬を集めているが、いま彼らが分裂の危機に瀕している。REST論壇を真っ二つに分ける激論が勃発したのだ。議論の火種となったのは 「恋愛は“GET”で表すべきか、“PUT”で表すべきか」 というもの。 リソースへのアクセスメソッドをGETにするかPUTにするかは、REST信者にとっては美しいWebサービスを設計するうえでもっとも重要な問題だ。ここで「恋愛はGET」と主張して譲らないのが、業界でRESTエヴェンジェリストとして知られる株式会社リコーの山本陽平氏。
2年間 WEB+DB PRESS で連載してきましたが、今回ついに最終回となりました。 正直 REST ネタでこんなにも書くことがあるのかと今でも不思議です。 ほとんどコードが登場しないで文字ばかりという異色な連載を載せ続けてくれた編集部さんに感謝です。 あと毎回締切ギリギリになってすんませんでした。 ところで最終回のネタですが、連載を始める前からずっと書きたかったリソースモデリングについてやっと書くことができました。 まだまだ確立された手法とは言い難いですが、僕なりにまとめてみたものです。 みなさんの Web システムを RESTful にするお手伝いができればいいなと思っています。 ありがとうございました。 WEB+DB PRESS Vol.49WEB+DB PRESS編集部技術評論社 2009-02-24
さて、このシリーズも今回で最後です。遅れに遅れて申し訳ありません…ちなみに昨年の12/22付けで仕様書が改訂され、私が指摘したところが直っていました。どうもありがとうございます>中の人 最後は設計編です。 今回、私がはてなダイアリーAtomPubの仕様を見ていて、設計面で疑問に思ったのは次の2点です。 X-HATENA-PUBLISH HTTP ヘッダ エントリ文書の対称性 以下ではそれぞれについて具体的に検討してみます。 X-HATENA-PUBLISHヘッダ いくつかのブログでも指摘されていますが、はてなダイアリーAtomPubではapp:draft 要素を利用しません。 はてなダイアリーAtomPub仕様書によると、以下のような理由があるそうです。 はてなダイアリーAtomPubでは、AtomPubで規定されているapp:draft要素を使用しません。はてなダイアリーでは日記エントリ
国島先生や斉藤先生が XML や半構造データについていろいろ書いてくださっており、それに反応する形ではてなブックマークや twitter 上での議論が日本語で進んでいて面白い。 http://kunishi.blogspot.com/2008/12/twitter.html http://leoclock.blogspot.com/2008/12/relational-style-xml-query-sigmod-j.html http://kunishi.blogspot.com/2008/12/xml-db.html ブックマークや twitter で細かいコメントを書いているだけでは申し訳ないような気がするので、久々にエントリを書こうとしたのだけれど、なんだかバックグラウンドが長くなってしまった。最先端の研究者のみなさんに失礼な物言いもありますが、XML guy としては XML の
以前、RESTfulWebサービス読書会の議論の中で、「RESTは目的ではなく手段である」というような言葉があって、「それはまさにその通りだよな…」と思った訳ですが、その時から「じゃあ、RESTが目指す目的ってどこ?」なんて事をぼんやり考えてました。 8月の読書会は諸々の理由から中止になった訳ですが、スタッフだけで反省会と称して色々と議論をして*1、そのぼんやり考えていた事が少しばかりクリアになって、考えが少し前進できた気がするので、アウトプットしてみようかと思います。 RESTful読書会の反省会で得た自分的結論 反省会で色々と話をした結果、結局のところ、第0回読書会で話されていた内容に4ヶ月間掛けてやっと実質的に知識が追い付いたんだという事が分かりました…。(^^;ゞ 時間はずいぶんと掛かりましたが、自分の感覚としてRESTfulな考え方が身に付いたという意味では意義があったと思います
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 Webサービス」第1章のまとめ † 第1回読書会 まとめにもどる 第1章「プログラマブルWebとWebサービス」について説明および議論がありました。 第1章を担当された高木さんの資料はこちらで公開されています。 ↑ 高木さんによる説明 † 1章で扱う内容は「次章以降を読み進めるための準備」 「RESTfulなWebサービスとはなに?」というのをはっきりさせることが目的 Webサービスを分類してみる 外見(テクノロジ)ではなく設計理念による分類 すべてのWebサービスに共通していること HTTPを使用する HTTPって? ドキュメント(文書)をエンベローブ(封筒)に入れてやりとりする仕組み エンベローブの形式は決まっている ドキュメントの形式にきまりはない Webサービスによって異なること メソッド情報の伝え方 スコープ情報の伝え方 メソッド情報? Webサービスで「どんな
1月に三分の一を公開して以来、ずるずると遅れていた残りの記事の公開をやっと行いました。 RESTアーキテクチャスタイル入門 Web アプリケーションのアーキテクチャ Web サービスと REST RESTful な URI の設計 出版は2006年なので2年前の記事です。内容が一部古くなっている部分もあったため、現時点での最新情報に少しだけアップデートしました。
このサービスで提供するリソースは、以下の3種類の表現を持ちます。 XHTML Media Type: application/xhtml+xml; charset=utf-8 標準的な Web ブラウザで表示することのできる形式です。ブラウザで表示させることが可能なので、人間が読みやすいのが特徴です。この表現は整形式の XML であるため、XML パーサーでパースして、プログラムから扱うことも可能です。住所の構造情報は class 属性で表現されています。全てのリソースのデフォルト表現になっています。 この表現は妥当な XHTML 1.1 になるはずですが、あえて DOCTYPE 宣言は付けていません。文字エンコーディングスキームは UTF-8 です。 http://zip.ricollab.jp/1120002 http://zip.ricollab.jp/search?q=大手町 ht
_ AtomPub で複数リソースをまとめて POST する方法 [atompub][opensocial][gdata] (2008-06-29 追記) その後の動向を書きました [2008-06-29-1] (追記) yohei さんからのコメントです. 解決策はたくさんあり、結局要求次第と思われ。やりたいことによって解 決策 が異なるので、仕様に入れないのは正しいと思う。個人的には複数 同時にPOSTすると、レスポンスが multi status に... (追記) enclosure or content/@src について lyokato さんとのやりとりです. lyokato: あー、日記と同時に関連写真を投稿したいとか、そういうケー スかなと思ってました。その場合はここで書かれた処理の後、enclosure link突っ込んだ日記entryのpostでいいのかしら? take
リリース、障害情報などのサービスのお知らせ
最新の人気エントリーの配信
処理を実行中です
j次のブックマーク
k前のブックマーク
lあとで読む
eコメント一覧を開く
oページを開く