ricollab Web Tech Blog » Blog Archive » はてなダイアリーAtomPubレビュー: その2 ドキュメンテーション編
その1を公開してからだいぶ時間が経ってしまいましたが、その2を公開します。今回はドキュメンテーション編です。 レビュー対象ははてなダイアリーAtomPubの仕様書です。普段私が業務で仕様書をレビューするときに気をつけている観点をご紹介しながら、いくつか指摘をしてみます。 なお、レビューの指摘はどうしても細かくなってしまうので、粗探し的と感じられてしまうかもしれませんが、技術的な完成度を上げるためには必要な作業なのでご容赦ください。 基本的な文章チェック まず、仕様書に記述されている文章の「てにをは」や文法レベルでのチェックをします。表記ゆれなども含まれます。 今回の仕様書は、たとえば以下のような記述がありました。 「ヘッダ」と「ヘッダー」、「XML文書」と「XML文章」、「はてなID」と「はてなアカウントのid」などの表記ゆれ。document に対する訳語は通常は「文書」を用います 「～
ricollab Web Tech Blog » Blog Archive » はてなダイアリー AtomPub レビュー: その1 実装編
はてなさんがダイアリーのAtomPubインターフェースをリリースしていました。 私は AtomPub が大好きなので、少しだけ試してみました。簡単にレビューを書こうと思ってエントリを起したのですが、意外と長くなりそうなので3部構成でお送りします。まずは実装編です。 認証 とりあえず普通のGETリクエストをサービス文書に送ってみます。http://d.hatena.ne.jp/{hatena-id}/atom がサービス文書の URI です。 GET http://d.hatena.ne.jp/yohei/atom HTTP/1.1 Accept: */* Host: d.hatena.ne.jp HTTP/1.0 401 Unauthorized Date: Fri, 19 Sep 2008 07:00:10 GMT Server: Apache/2.2.3 (CentOS) WWW-Au
yohei-y:weblog: APP の標準化作業がほぼ終了
Tim Bray からアナウンスがあったとおり、 APP の標準化作業がほぼ終了しました。 RFC 番号が付くのはしばらく先だと思いますが、 現状の仕様を実装してもう問題ありません。 最後の draft-17 ベースの仕様が RFC になります。今後の修正は editorial なものだけのはずです。 この先、Web API を設計する人は、まず APP が利用できないか検討しましょう。 APP を採用すれば自然と REST スタイルを採用することになります。 これまで悩みがちだった Web API の設計が、かなり楽になると思います。 Web API を設計する人は、オレオレXMLを設計する前に、Atom/APP をベースにしたらどうなるか、 を考えて見ましょう。きっと Atom/APP は良い選択肢になってくれるはずです。 日本では AtomPP で定着しつつあった Atom Publ
A Week in the Valley: GData - O'Reilly Radar
I spent the week before Where 2.0 visiting companies between San Francisco and San Jose. I've already written about my trips to Ning and Meebo. Next is an account of a meeting with Mark Lucovsky, who was architect of the HailStorm web services product from Microsoft. I had a great lunch with Chris DiBona and Mark Lukovsky at Google. There's a huge move within Google away from SOAP and even REST-st
[観] ココログの生成する Atom 1.0 フィードの中身がおかしい
[要旨] 昨日(2006年6月24日)から、ココログの生成する Atom 1.0 フィードの中身がおかしくなっています。 [キーワード] Atom,フィード
ブックマーク件数取得APIをリリースしました。 - naoyaのはてなダイアリー
exist API を使えば HTML をスクレイピングするより高速な実装が可能ですが、それでも一画面に 50 件検索結果があったりすると 50 回 exist API を叩くことになって HTTP のオーバーヘッドが大きいでしょうし、サーバー側も SQL が 50 回走ったりして嫌なので、前から考えてた複数 URL を与えてブックマーク数をまとめて取得する API を作ってます。来週にはリリースしたい。 ということで、はてなブックマーク件数取得APIをリリースしました。相変わらず名前がださい。JSON版とかMD5で問い合わせられるようにとかはまた後ほど。 はてなブックマークはそんなにサーバーの台数もまだないので、連続リクエストはすこし間隔あけてもらえたりすると助かります。 そうそう、こういう API を AtomPP で実装するとしたらどんな感じなんだろう。そもそもうまくフィードで定義で
ぶろぐ。@4bit.net: Atom + OpenSearch
« AtomPPに検索って無いの？ | メイン | はてなブックマークは便利だけど… » 2005年07月06日 (水) Atom + OpenSearch [テクニカル] 昨日のAtomPPの検索のつづき。YAMAMOTO Yohei氏の関連記事を読み進めながらいろいろ調べてみると、A9 OpenSearchに話がつながることがわかった。やっと数ヶ月遅れで話題に追いついたのかな。yohei氏の記事ではAtomフィードを拡張してOpenSearch RSSを追加する例が示されている。 でもOpenSearchってなんか方向性が違う気がするんだけど。検索エンジンのインタフェース統一なんて高尚なものではなくて、AtomがPublishing ProtocolとしてCRUDを実装するなら当然検索も必要です、と言いたいだけなのだ。CRUDのRは、ReadだけではなくてRetrieveもあるのです（
Atom Publishing Protocol の範囲での拡張案 - 活動メモ 2nd season
概ね、yoheiさんの案に同意します なにはともあれはリソースのことを考えよう。タグをリソースとするならまずはそれに URI を割り当てなければならない。僕(yohei) の "atompp" というタグの URI は以下のような形式とする。 http://b.hatena.ne.jp/atom/yohei/tag/atomppyohei-y:weblog: はてなブックマークのタグ編集に Atom PP を用いる件について 興味深く拝見させていただきました。 http://b.hatena.ne.jp/atom/ユーザ名/tag/タグ名 で、指定ユーザの指定タグの情報が操作できるようにしよう、というのには賛成。 ただし、タグの取得(GET)に関しては、本人以外も実行できるようにして欲しい。 POST, PUT, DELETE に関しては本人のみ実行可能ということで。 さらに、 http:
ちょっとしたメモ - Atomのcategory要素とURI参照
Last Callといいつつ6月7日にはまたID-9が出ていたりするAtomのシンジケーション書式仕様だが、ID-04から取り入れられていたcategory要素について、少し補足説明しておこう。 Atomでは、feed要素、entry要素ともにその「カテゴリー」を示すcategory要素を任意の数、持つことができる。これは、カテゴリーを示す分類名をterm属性（必須）で記述したうえで、必要に応じてそのスキーム（名前空間）のIRIをscheme属性で加えてもよいというもの（さらにlabel属性も使える）。たとえば、あるウェブログ・エントリーが音楽について書かれていることを示すなら、次のような具合だ： （例） <category term="Music" scheme="http://xmlns.com/wordnet/1.6/" label="音楽"/> これはなかなか面白い仕掛けになってい
1
リリース、障害情報などのサービスのお知らせ
最新の人気エントリーの配信
j次のブックマーク
k前のブックマーク
lあとで読む
eコメント一覧を開く
oページを開く
http://mummola.cs.tut.fi/atompp/
http://sionne.just-size.jp/rnote/rnote.php?u=2005/07/0507070717.htm
はてなブックマークフィード仕様とは はてなの人気・最新記事を集めました - はてな
『yohei-y:weblog: はてなブックマークのタグ編集に Atom PP を用いる件について』へのコメント
はてなフォトライフAtomAPI