サクサク読めて、アプリ限定の機能も多数!
トップへ戻る
Wikipedia
yohei-y.blogspot.com
» REST 入門 目次 僕の説明だと、どうもアーキテクチャとアーキテクチャスタイルについて混乱を招きそうなので、 補足しておきます。 デザインとデザインパターンが違うように、 アーキテクチャとアーキテクチャスタイルは別物です。 デザインパターンの本といえば GoF とか結城さんの2冊が有名ですね。 デザパタ本に載っているのはデザインそのものではなくデザインのパターンです(ムズカシイ?)。 つまりこういうことです。 僕たちは結城さんの本でデザインパターンを勉強します。 デザインパターンはある問題領域においての経験則的なクラス設計の指針、作法、流儀です。 あの本自体に自分のプログラムのデザイン(設計)が書いてあるわけではありません。 本に書いてあるパターンを学習して、そのパターンを自分自身のプログラムのデザインに適用します。 デザインというのは本に書いてあるのではなく、 僕たちが実際に作るプ
blogger が落ちてたんで遅くなりました。 http://subtech.g.hatena.ne.jp/miyagawa/20060509/1147161767 http://naoya.g.hatena.ne.jp/naoya/20060509/1147157679 この Hack が素晴らしい。で、見てておもったんだけど、ウェブのフロントエンドアプリケーション作りが得意な人は、そのフロントエンドアプリケーションから利用するバックエンドの API を規定して、API のエンドポイントを任意の URL に設定できるとかそういうものを作ったりとか、そういう時代が来る。 大体近いんだけど、ちょっとまとめ方が違ってる。 (中略) Amazon Web Services みたいな、「APIでデータとれるのでどうぞあなたのアプリでつかってください」っていうのが旧時代の Web API で、Ama
日経SYSTEMS 5月号で Web 2.0 関連技術(特にREST)がシステム開発に与える影響についての取材を受けました。 P60に数行だけ僕の発言が引用されていました(下記に引用したので全文)。 僕がしゃべったこととはちょっと違ったのでここで訂正しておきます。 コンテンツを読むだけでなく、簡単に書き込めることが重要。 これはそのとおり。 REST では GET に PUT と DELETE を加えれば Web ブラウザだけでそれが簡単に実現できる。 これは言ってないよー。ブラウザだけで簡単に実現はできないっしょ。少くとも現時点では。 新たに SOAP を覚える必用がない まあそうかもしれない。ただ、これに相当することを言った覚えはないんですが…。
naoya さんが先に言及してくれてますが、WEB+DB PRESS Vol.32 に 「REST アーキテクチャスタイル入門」という記事を書きました Web アプリケーション開発者の方を対象に Web アプリでの REST から Atom Publishing Protocol まで、 かなり細かく解説したつもりです。 はてな技術発表会で naoya さんが XML 開発者の日の参加報告をしているのを聴いて、 普通の Web アプリケーション開発者の人にももっと REST を知ってもらえたらいいなと感じたのがその理由です。 なのではてなスタッフの方々にはぜひ一人一冊ずつ購入していただければと:-)。 ただ、やっぱり REST は難しいですね。人に説明するたびに思います。記事でわからないことがあれば、ここにコメントしていただければできる範囲で返答しようと思います。
昨日デジハリで行われた Shibuya.js Technical Talk#1 に行ってきました。 id:secondlife さんの結成宣言に始まり、 えとさんによるこの10年と次の10年の話、 IT戦記 amachang さんが javascript を300倍高速化した後、 竹迫さんによる爆笑プレゼン、 mala さんが自身の開発環境+ポリシーを余すことなく公開し、 id:secondlife さんから RJS Template のソース嫁とありがたいお言葉を頂戴して、 怒涛のライトニングトークの最後は怖いビデオをマッタリと視聴しつつ、 id:thx さんの軽快な司会て幕を閉じました。 どの発表も大変面白かったのですが個人的には cho45(さとう)さんの $X リスペクトです。 僕もグリモンスクリプトをちょこちょこ書いて遊んでいるんですが、 ちょっと前に見つけたこの $X なしでは
Tim Bray の WS-Crossroads から REST 関連のブログエントリが凄いことになってます。 Tim のエントリはガートナーの group VP で chief fellow な Daryl Plummer の Web Services At A Crossroads という記事を受けてのもの。 Plummer の文章はツッコミどころがあるものの、いいこといっているのも事実だと。 Tim のエントリは最後の段落がとてもいいです。 Speaking for myself, not for Sun, I think that we ought to be pouring resources and investment into tooling and developer support around simple XML/HTTP/REST technologies. Yo
前のエントリでこんなことを書いたばかりだけれど、REST ってやっぱりどうよ、という気分になったので久々に blog を更新してみる。 ただただしさんのおれだったらフォト蔵APIをこうするを読んで、僕が del.icio.us に書いた感想は +1。ID == URI ですよね。Cool URI は名詞であるべき、というのは強調したい。「日本REST協会」入りたくないなー(笑)。みんな休んでそう というもの。たださんのエントリでは URI と書くべきところが ID になっててちょっと気になったり、「作法」は「アーキテクチャ」じゃなくて「アーキテクチャスタイル」だ、とか思ったのだけれど、でも本筋としては納得の内容だった。 しかし、たださんのエントリの、たかはしさんや mizzy さんのコメントを読んでうーんと唸ってしまった。 僕にはお二人の言いたいことがわかる。んで両方間違っていないと思う。
知り合いに教えてもらって知ったのだが、今月の日経ソフトウエアは Web プログラミングの特集である。 ちょっと立ち読みしたところ、内容は Web 2.0 まわりの記事だった。 その特集の中の囲み記事で REST と僕の名前が出てくるところがある。 「わかりづらい REST という言葉」というタイトルで、 REST がアーキテクチャスタイルであること、 一方で REST API は「ホームページ」のような誤用であるが、そちらの方が一般的になってしまっていること、 が簡単に記述されていた。 REST == HTTP GET+XML のような紹介よりも1万倍よかったし、 何よりこういう初心者向けのメジャー(?)な雑誌記事で REST に言及するよ うになって、本当によかったと思う。1年前には考えられなかったことだ。 ただ、気になったのは REST が難しくてわかりづらい、という話だ。 そりゃ確か
なんか催促されちゃったみたいなので :-) 詳しく書いてみます。 はてなのブックマーク件数取得 API いいですね。 今さら xml-rpc かよ! というツッコミは置いておいて、 データ重要な世の中で有用なコンテンツ(メタデータ)にリーチする 方法が増えるのは喜ばしいことです。 そうそう、こういう API を AtomPP で実装するとしたらどんな感じなんだろう。そもそもうまくフィードで定義できるのか。教えて偉い人! 偉い人じゃないけど、結論からいえば、 Atom Publishing Protocol (APP) そのままじゃ無理です。 やってもいいけどどうしても無理が出てしまいそう。 そもそも目的が違うのだから、ここは野良 XML/プロトコルでいいのでは。 ただ、結果をフィードで取れるとそれなりに嬉しいかもしれない。 普通 REST で検索するときは query string を使っ
自己紹介� 名前�� YAMAMOTO Yohei 職業 ソフトウェアエンジニア(XML guy) 興味 XML/Web サービスの設計一般 連絡先�� yoheiy at gmail dot com 注意書き この日記に記述されている内容は、筆者の個人的な主張や考えであり、筆者の勤務する企業や属する組織とはまったく関係ないことをお断りしておきます。
Paul Prescod の Common REST Mistakes の翻訳版を公開しました。 本当は今年の1月に訳してたんですが、諸般の事情で公開するまでに時間かかってしまいました。また、村田さんからたくさん助言をもらって訳文を修正してあるんですが、それでも Paul の文章は僕には難しくてあんまり読みやすい日本語にはなってません。ただ非常に含蓄のある内容ですのでぜひ原文とあわせてご覧ください。 3 Comments: At 2006年3月7日 13:40:00 JST, Unknown said... 2点質問です。 「6.セッションは関係ない。 」に「あらゆるメッセージについて自動的に HTTP 認証は行なわれる。」という記述がありますが、BASIC認証ならOKとかいう話なのでしょうか? 「クライアントアプリケーションは、リソースを使うのであってサービスを使うのではない。 したがっ
昨日、第八回XML開発者の日が開催されました。死ぬほどつかれたけれど、死ぬほど面白かった。こんなにまじめに一日中頭を使って人の話を聞いたのは久しぶりです。 僕の発表資料とパネルのときに即席で作ったスライドです。発表資料の方はもんたメソッドなのでスライドショーで見てください。パワーポイントない人は OOo でお願いします。(2006-04-11 置き場所修正) 以下、感想とまとめです。 REST入門 山本陽平(株式会社リコー) REST の入門編を喋ってみました。 なるべく基本的なところを丁寧に話したかったんですが、成功したかどうか… コネクタの話をしなかったので、高橋さんにちょっとご迷惑をおかけしました m(_ _)m はてなとREST API 伊藤 直也(株式会社はてな) モテ重要、ということでなんではてなが APP を採用したのか、 その根底に流れるデータ重要という考え方、 サーバサイ
Dare Obasanjo の blog で知ったんですが、 Microsoft Team RSS Blog より Our years of experience in with HTML in Internet Explorer have taught us the long-term pain that results from being too liberal with what you accept from others. Hence, we’ve adopted the following overriding principle for IE 7 and RSS platform in Windows Vista: We will only support feeds that are well-formed XML. This principle allows us to
村田さんからアナウンスがあったとおり11月24日(木)に新富町の印刷会館で XML 開発者の日が復活します。 5月の WWW2005 で村田さんにお会いしたときに、 開発者の日で REST を扱いたいですよね、 という話をしていたのですが、 画像電子学会という事務局がみつかって開催のはこびとなりました。 REST について議論する場がずっと欲しかったので、 今回は僕も準備のお手伝いをさせてもらいました。 具体的には何人かの発表者の選定や連絡などさせてもらってます。 さて、プログラム(予定)ですが、 現時点で REST の話を日本語でするなら ほぼベストな布陣になっていると我ながら思います。 以下では僕の独断と偏見で、各講演の見どころ聞きどころを説明したいと思います。 REST入門 山本陽平(株式会社リコー) 朝イチで僕が REST の入門編を喋ります。 ベースはこの blog の REST
僕もご多分に漏れず Javascript で遊んだり調べたりしています。 いろいろなクールなサイトの生 Javascript を見て勉強しているのですが、 まず面白いなと思ったのがロールオーバーの実現方法です(JavaScript や HTML をわかってる人には当たり前の内容だと思うので、ツマラナイ話だと思いますが)。 WaSP の左上の画像のロールオーバーは <img id="logo" src="/img/logo.gif" height="100" width="103" alt="Web Standards Project logo" /> 生 HTML はこんなかんじで onmouseover/onmouseout 属性を記述せず、 JavaScript で function initRollOvers() { var logo; if (document.getElement
僕が提案した方法についておのひろきさんからツッコミが入り、 microformats を誤解している、マークアップする力の問題である、と批判されました。 まー実際、microformats を誤解しててマークアップする力もないかもしれないんだけど、 おのひろきさんの主張には賛成できないので、ここでまとめて反論しときます。 まず、「microformats についての誤解と,ぼくが理解している範囲」より。 前半の microformats の説明は特に異論はありません。 でもそれがなんでいきなり それでさらに microformats であるなら,一度「意味付けと記述書式」を決め たら,それが他での使い回す事ができないと意味がありません.限定された問 題を解ければ良いとはいっても,特定の問題にしか対応できないほど限定して たら駄目なのです. ってなっちゃんでしょう?(強調筆者) ここがまずわ
URI は綺麗であるべき、と常々思っているんですが、よいページを発見しました。 Michael Eakes のこのエントリです。 Tanya Rabourn がリストアップしている文献一覧からエッセンスをまとめてくれています。 曰く、よく設計された URI とは 変らない(don't change) 人間が推測可能(are human guessable) 論理的(ファイルシステムを反映する必用がない) (are logical (no need to mirror a filesystem)) サイト構造をビジュアライズするのに役立つ(help visualize the site structure) 短い(are short) 小文字を使う(use lowercase) 予期されない記号を使わない(don't use unexpected punctuation) 問合せパラメータな
前のエントリで触れた ID だけのディスカバリの問題点ですが、 他にもこんなのもあります。 僕が自分のブログにはてな ID を埋め込んだとして期待するのは、 ブログを訪れた人が自分のブックマークやアンテナを見に来てくれたり、投げ銭してくれたりすることです。 でも僕がはてなで何を使っているかは僕にしかわかりません。 僕の場合はてブとはてアは使ってるけど、 はてダは更新を止めちゃった、はてフは知らん、という状況です。 もしかしたらアサマシは嫌いだから投げ銭してほしくない、という人もいるかもしれない。 これって「はてなID」の埋め込みだけでは実現できません。 自分ははてなのこのサービスを使っているよ、という主張をできないからです。 ではどうするか。 自分ははてなのこのサービスを使っているから見に行ってね、という宣言をしたらどうでしょう。 head 内で宣言するんだったらこんな感じ。 <link
昨日は SIGMOD-J の大会に行った後にアルファギークなお二人と食事をしてきました。 大会ではやはり naoya さんの Web 2.0 についての話が一番面白かったです。 周りにいた人の反応も一緒でした。 ちなみに僕は naoya さんは初対面。 食事に途中参加の高林君とはちょうど4年ぶりだったことが今判明。オリンピックみたいだ:-)。 naoya さんは普段から blog やブックマークを見ているので、ぜんぜん初対面な気がしなかったんですが、 僕としては REST だの Folksonomy だの microformats だのといった単語をガンガン喋ったり聞いたりするのが新鮮かつエキサイティングでした。 やっぱり直接会って話すのは大切だと実感です。 以下本題です。僕は話題に出遅れてしまったんですが Hatena ID Auto-Discovery について。 naoya さんには
Atom Syndication Format 1.0 が Tim Bray からアナウンスされましたね。 いろいろなところで言及されていますが、 XML cover pages がいつもながら一番まとまっています。 ちなみに RSS/Atom のこれまでの流れは Robert Sayre の記事によくまとまっています。 これで syndication format の本命は RSS 2.0 と Atom 1.0 に絞られたわけですが、 これからどうなるか注目です。 両者の比較は Tim Bray のもの(日本語版)がありますが、 はっきりいって機能的にはそんなに違いませんね。 Atom 1.0 の方が後出しジャンケンなので全体的にすっきりしていますが、 普及状態から言うと圧倒的に RSS 2.0 が勝っています。 Atom の方はもちろん syndication format 単体で使え
楽しそうなので、考えてみることにする なにはともあれはリソースのことを考えよう。 タグをリソースとするならまずはそれに URI を割り当てなければならない。 僕(yohei) の "atompp" というタグの URI は以下のような形式とする。 http://b.hatena.ne.jp/atom/yohei/tag/atompp 次に考えるのはタグリソースの 表現に何を使うか。 構造を持った情報なので XML になるのはすんなり確定。 問題はその形式。候補は以下のとおり。 最新 AtomPP のメンバー要素(member) 長所: 軽い、簡単 短所: member/@href で参照する先の URL はどの XML 形式にする? あるいはタグ名のテキスト(plain/text)か? Atom の entry 要素(entry) 長所: 標準。使える子要素がいろいろ定義されている 短所:
Microformats の嬉しさについて。 Technorati が推進していることからもわかるとおり、一番わかりやすいのは blog 検索の精度向上だろう。 たとえば hReview でブックレビューを書いておけば、 たとえば hCalendar でカンファレンスのスケジュールを登録しておけば、 たとえば rel="license" で自分の記事や写真を CC ライセンスにしておけば、 あなたが提供しているその情報を必要としている人に届きやすくなる。 あるいは今流行の Musical Baton で他の blog にリンクするときに XFN で友人・知人関係を記述しておいたらどうだろう。 こんなアイデアを自動化しつつ さらに参加者間のリンクを関連で色分けして表示するアプリが作れそうだ。 そんなの前からできたって? そう、メタデータを駆使したセマンティックウェブを使えば前からできた。 M
REST -> AtomPP -> blog -> Permalink -> RSS/Atom -> Remixing (Ajax/Microformats/Folksonomy) 少し前の話だが、Blog Hackers Conference 2005 に行った。 miyagawa さんのキーノートも、naoya さんの講演も、キーワードは Web 2.0 (的なもの)だなという印象だった。 中でも特に気になったのはこのスライドで blog が missing piece を埋めた、という話だ。 こちらのコメントにも書いたのだけれど、 ここでいう blog というのはいわゆる weblog system/service だけを指すのではなくて、 blog 周辺の技術 (RSS, Atom, AtomPP, REST, Permalink) が方法論として、プラットフォームとなる、というの
CDF を覚えている人はいるだろうか。 たとえば このファイル をダウンロードして、デスクトップに保存してみてほしい。 Windows を使っている人なら、アンテナのアイコンが現われるはずだ。 ためしにダブルクリックしてみよう。 あやしげなダイアログボックスが表示されるだろう(キャンセルしといてね)。 右クリックしてみよう。 いっぱいメニューが出てくるはずだ。 エディタで開いてみよう(「右クリック→編集」でもよい)。 タグ名が大文字の見なれない XML ファイルである。 これは XML の創世記に話題となった Channel Definition Format (CDF) だ。 覚えていない人、あるいはそもそも知らない人のために解説すると、 CDF は XML の最初のアプリケーションとして 1997-1998年当時に大変注目されていた技術である。 タグ名が大文字なのも、当時としては普通の
» REST 入門 目次 前回まで、REST 入門ということで、 REST アーキテクチャスタイルとは何なのか、 について基礎的なところを結構細かく :-) 説明してきました。 REST 入門はこれで終わりですが、最後にロイ・フィールディングの論文から REST アーキテクチャスタイルの各制約を抜き出して説明します。 Null スタイル 最初は、制約がまったくないところからはじまります。それが Null スタイルです。 クライアント・サーバ 最初の制約はクライアント・サーバです。REST がクライアント・サーバから派生していることは、 "2. アーキテクチャスタイルとは" で解説しました。 ステートレス REST スタイルにおいて、サーバはクライアントの状態を管理しません。すべての状態はクライアントで持ちます。 クッキーでの状態管理が REST でないことは "8. REST でないもの"
» REST 入門 目次 前回、WWW のうち REST アーキテクチャスタイルに従っていないものについて解説しました。 今回は「その筋」では有名な REST と SOAP の対決の概略を解説します。 Google で "REST vs SOAP" あるいは "SOAP vs REST" を検索すると、 たくさんの Web ページが見つかります。 いろいろな立場の人が、それぞれの意見を述べ合っていて、 ここで全ての主張や意見を解説するのは不可能です。 これから解説する内容は、あくまでも個人の意見ということをご了承ください(まー weblog なんてそんなもんですが)。 ところで最初からこんな話をするのもアレですが、 REST と SOAP は比べられるものなのでしょうか。 REST はこれまで何度も述べてきたとおり、ネットワークシステムのアーキテクチャスタイルです。 一方で SOAP はプ
疎結合(loosely-coupled)って何でしょう? 僕自身、適当に疎結合という言葉を使ってしまいがちですが、 ちゃんとした説明なり定義なりが必用だと感じています(自分のために)。 いいかげんな定義で話をはじめると、 各人の方向性がずれまくって議論ができないですよね。 Web サービスしかり、 SOA しかり、REST しかり。 ということで今回は僕なりに疎結合ってこんなもの、 というのを考えてみます。 ものすごく一般化してしまうと、 疎結合というのは複数のコンポーネント間の結び付きが ゆるいことを指すんでしょうね。 たぶん、ここまでは誰でも同意してくれるはず。 ただこれだけでは議論ができなくて、 このコンポーネントに何をもってくるかを決めて、 はじめて具体的な話ができます。 僕がここで話したいのは Web サービスの文脈での「疎結合」ですから、 コンポーネントは Web サービスにな
» REST 入門 目次 kwatch さんから以下のようなコメントをもらいました。 POSTとPUTの説明が逆では?たしかPUTが新規作成であり、POSTは送ったリソースの処理を指定したURIに任せるということだったと思いますが。 コメント欄では返答が書ききれなかったので、補足として新しいポストを追加します。 RFC2616 では PUT の動作が二つ規定されています。 指定した URI がすでに存在している場合 PUT はその URI のリソースを修正(更新)する 指定した URI が存在しない場合 PUT はその URI のリソースを新規作成する PUT を規定している 9.6 節には POST と PUT の違いとして以下の記述があります。 The fundamental difference between the POST and PUT requests is reflect
naoya さんのダイアリーに端を発してちょっとだけ議論が起きている。 まず naoya さんのオリジナルのポスト。 はてなが従来のいわゆる世間一般の開発手法を採用せず Perl でアジャイルな開発手法をを選ぶ理由として、 その開発するソフトウェアサービスの性質と 動的型付け言語の開発効率を挙げている。 対してオリオナエさんは naoya さんがソフトウェア工学を軽視している(ように見える)点を、 薬学と建築工学の例を使って批判している。 吉松さんははてなのサービスとオリオナエさんの薬の例のギャップを指摘して、 いわゆるソフトウェア工学的手法に疑問を投げかけておられる。 Don'tStopMusic さんもオリオナエさんの例とはてなの違いから いわゆるソフトウェア工学(と Java)ははてなには合わないという主張だ。 ここまで読んで思ったのは、みなさんの「ソフトウェア工学」感のずれだ。 そ
次のページ
このページを最初にブックマークしてみませんか?
『XML と REST/Web サービス関連の話題が中心の weblog です』の新着エントリーを見る
j次のブックマーク
k前のブックマーク
lあとで読む
eコメント一覧を開く
oページを開く