お問い合わせ
会社概要 ソフトウェア 開発ブログ サポート

2006年08月24日

GData API for Google Base

という事で、期待していた通り、Google Base APIが公開されたようです。

New GData API: Google Base
http://code.google.com/apis/base/

ただ、やっぱりGoogle Base自体がまだ内容的に欧米セントリックという所があるので、(というかGoogle Base自体日本語化されていない?)ちょっと残念ですが、このAPI公開は多方面で非常に意味があるなぁと思います。検索エンジン業界にとってもその他の分野でもこの意味は長い目で大きな影響がある気がします。

関連記事:
Google Base
不動産物件情報とXML(Google Base)

投稿者 BlogWrite担当 : 04:11 | コメント (0) | トラックバック

2006年03月06日

RESTなWebAPIの開発支援ツール

技術者向け記事です。ご興味ない方には申し訳ありません。

ちょっと前になりますが、RESTのAPIを開発する上で便利かもしれない社内製ツールを公開しました。5年ぐらい前に学習目的で作ったXMLエディタとBlogWriteの通信部分をくっつけてゴニョゴニョとやったものです。

因みに、「The Future of Web Apps」 Webアプリの未来 - と題したコンフェレンスのポッドキャストをやっと消化し終わりました。

このコンフェレンスでは、Googleマップの開発者、米Yahooの人、Ruby on Railsの人、Delicious、Flickr、などなど最近の代表的Webアプリケーション開発者が集まった豪華なメンバー..。どの話にも共通していたのは、やっぱり、APIの事でした。OpenなWebサービスAPI重要。

The Atom Publishing Protocolもある程度形になってきましたし、日本でもRESTについて、APIについてそろそろ盛り上がってきたこの頃、皆様いかがHackしておられますでしょうか。

自分がAPIのサーバー側を作ることになって気が付いたのが、API自体の設計や開発、テストをする上で面倒な事は、サーバー側のアプリケーションとクライアント側アプリケーションを両方作らなければならない、という事でした。サーバー側を作ってテストするには、クライアントも同時に作らないと行けません。インターオペラビリティを確保するためにも、第三者が作ったクライアントがあった方が良いです。ところがクライアントは、世の中に存在していないAPIに対応したり、サーバー側アプリケーションが動いていない中ではどうしても作りにくいものです。まさに鶏と卵。

では、汎用的なRESTfull APIクライアントがあれば、Web APIを実装する際、特にサーバー側で実装する際、色々と便利ではないでしょうか。ブラウザではGETは出来てもPUTやDELETEは出来ませんし、ヘッダー周りや内容を変更する事は難しいです。

そこで、POSTやPUTする場合、Bodyに含めるXMLを予めファイルで用意しておけば、後は随時、任意のXMLを開いて一発で指定したメソッドでHTTPリクエストを発行し、ヘッダを含むレスポンスも確認出来るようにしました。ついでにXML編集機能がありますので、設計段階から使えます。

もともとXMLエディタだったものをベースにしているので、POX(Plain Old XML)の作成編集、XSLTの作成編集プレビュー機能などもあり、Atom,RSSのGET、AtomAPI(GET,POST,PUT,DELETE)のテスト、XML-RPC(POST)のテスト、OPMLも直に読み書き(GET,POST)できるようにしました。

XMLを脳内変換出来る人はこれだけで、ウェブのRead/Writeが実現(w)、ブラウザいらず..というのは冗談です。

もしご興味がありましたら、
http://www.witha.jp/eXeries/ja/
からご自由にどぞ。 

追記:(2006/03/09)
英語版のページも作っておいたら、早速「ある本の著者なんだけど、スクリーンショット使ってもいいか」なんてメールが海外から来ました。楽しみ。

投稿者 BlogWrite担当 : 19:52 | コメント (0) | トラックバック

RESTという言葉の誤用について

あまり表立って、REST自体の事を詳しく書いてこなかったのですが、実は2003年頃から一歩引いた所からRESTには注目してきました。実際AtomAPIを知ったのもREST繋がりです。

最近、XML開発者の日を境に、RESTというアーキテクチャスタイルが日本でも広まりつつあるのですが、ちょっと誤用が増えてきた気もしないでもありません。

HTTPリクエストを使って、XMLが返ってくるものを何でもRESTと表現されてしまい、結局意味がバラバラで、バズワードのように濫用されるのではという懸念も一部ではあるようです。

実際、誤解を広げかねない説明をしているサービスもあります。 一例を上げると:

「REpresentational State Transferの略語。HTTPリクエストに対してXMLをレスポンスとして返す。********WebサービスはRESTを採用しています。」

HTTPリクエストを使えばRESTというわけではなく、URIとHTTPメソッドを正しく使う事が主眼Uniform Interface が重要であり、また、あまり知られていないのが、POSTのボディやレスポンスのボディは別にXMLである必要性はまったくない、という事です。ブラウザがバイナリチャンクでもステータスコードのみでもOK。XMLはしっかりと規格化されていて汎用性があるフォーマットだから多く利用されるだけです。 (例えばブラウザーが画像(リソース)をGETしてバイナリーで受け取った場合の振る舞いはRESTfullと言える。HTMLのページでも同様。ただ、ブラウザは通常POSTかGETしかしないのが問題。RESTを一言で言うと、本来のWebの用法に従うということ?)

なので、上記のREST定義は誤解を広げかねないと言えます。

ここで行き違いが生じやすいのですが、「POSTとGET、PUT、DELETEなどを使え」、と強制している訳でも、「RESTという言葉を使うな」、といっているわけでもないのです。単に言葉は正しく使いましょう、という事だったりします。 あえてRESTでない手法を選択したのであれば、それはそれで構わないでしょう。しかし、実態は異なるにも関わらずRESTと称するのは健康的ではない、というのが私の考えです。

つまり、 自動車を無理やり線路の上を走らせることが出来たとしても、それを電車とは呼びません。ただ「線路上走行自動車」でしょうか... これに準じて先の定義は、あえて言うなら、RESTでなく、「POX over HTTP」ぐらいにすべきでしょう。

「Web2.0」といった概念を表す言葉とは異なり、RESTアーキテクチャスタイルには、しっかりとした指針(UCIでの論文)があります。もしWebリソースの作成含めてすべてのHTTPリクエストにGETを使っていたら、それは正しくHTTPを利用しているとは言えず、RESTではないでしょう。

ウェブサイトのトップページを指す「ホームページ」が、いつのまにかウェブサイト自体のことを言うようになってしまったりしてますが、RESTという言葉が見当違いのことを指すようになったら、もっと困ってしまいます。私がもっとも懸念するのは、もし誤用が広まると、RESTというアーキテクチャスタイルを採用して健康的なWebAPIを作成しようという人たちが真の恩恵を受けられず、多大な迷惑を被ってしまいかねない、という事だったりします。

また、言葉だけで利点を理解するのは難しい時があります。ですから、実際にAtomAPIを利用するシステムを開発して見ると、本当のRESTと、そのリソースのURIに対し、POSTで新規作成、PUTで更新、という流れがシンプルで効率よく、設計が美しく感じられるようになるのではと思います。特にXML-RPCのような冗長で無駄の多い仕様を同時に実装して見ると、違いが実感出来ます。

関連情報:
REST 入門
REST の日本語リソース
ウィキペディア:REST
AtomAPI解説

変更履歴:
「アーキテクチャー」ー>「アーキテクチャスタイル」
「HTTPメソッドを正しく使う事が主眼」ー>「Uniform Interface が重要」
御免なさいm(_'_)m ビックル飲みまくり... 詳しくはhttp://yohei-y.blogspot.com/2006/03/rest.html

投稿者 BlogWrite担当 : 19:20 | コメント (1) | トラックバック

2005年11月25日

XML開発者の日へ

行って来ました。今日というかもう昨日...。久しぶりに刺激的な日でとても素晴らしかったです。皆さまありがとうございました。パネルであまり大したことはしゃべってなかったような気がしますが、キニシナイ..。

色々と意見交換できて最高でした。

早速Wikiを作成されていらっしゃる方が...。

追記:物凄い勢いでメール、サポートフォーラム書きコが溜まっていましたが、本日メールお返事力尽きてできなかったので申し訳ありません。

投稿者 BlogWrite担当 : 02:44 | コメント (0) | トラックバック

2005年10月18日

第八回XML開発者の日

というのが11月24日 、開催されます

RESTとAtom Publishing Protocol(AtomAPI、AtomPP、APP)を中心に、Web2.0時代を支えるRESTによるAPIや来年注目の技術トレンド話題のAtomAPIについてのイベントなのですが...。

えと、私もパネルでチョビット何か話す機会を頂きました。

なんか、はてなのNaoyaさん(アルファブロガー)とか、SixApartのhirataさん(日本のブログ界の立役者)とか、XMLの父とも言える村田さんとか、REST入門を書かれた yohei さん、RESTWiki を作った方、かの高橋メソッドの高橋さん...

そうそうたるメンバーです。

浮きそうです、というか浮いてます。

というか、AtomAPI、またの名をAtomPP、またの名をAPP、正式名称Atom Publishing Protocolとかいうのいいかげんに止めたい.^^; 

投稿者 BlogWrite担当 : 16:21 | コメント (0) | トラックバック

2005年09月16日

最新 Webサービス API エクスプロ-ラ

050916_1652.gif 最新WebサービスAPIエクスプロ-ラ ~Amazon、はてな、Google、Yahoo! 4大Webサービス完全攻略

一足早く見本誌を頂きました。(<- 携帯で撮った写真なので汚くてすみません)

つい最近も、Web 2.0 API Reference などで一覧が公開され、WebサービスAPIが注目されています。上記サイトについて、はてなブックマークのコメントとかみても、日本のサービスは?といった反応も見られ始めている中、タイミングよく、4大Webサービスを扱ったムックが発売されます。

今すぐ、Hackできる実用APIについて、これだけの情報が、ここまでまとまった形で手に入るのは稀有な事かもしれません。それぞれのサービスのAPIの紹介とその利用方法が具体的に詳しく紹介されています。 また、AJAXやGreasemonkeyなど旬の話題も扱っていたりと、至れりつくせり...。もうヤバイです。

始めのエントランス部で、とりあえずRSSとAtomについて、そして来年のWeb開発での注目トレンドの一つとの声もある、AtomAPIについて。そのあと、各サービスのAPIへ....。

この一冊で、WebサービスAPIの面白さを実感できると思います。

投稿者 BlogWrite担当 : 17:32 | コメント (1) | トラックバック

2005年08月02日

ブログ投稿APIと認知度

先日、某ブログサービスの中の人とお話できたのですが...。BlogWriteどころか、他の投稿ツール一般に関してご存知ないと、言われてしまいました。あまりのショックに引き篭もりたくなりました(笑)。

やっぱり投稿用ツールというかブログ投稿クライアントの存在自体、その認知度ってまだまだかなり低いんですね、便利さの割りに。もしテレビに出てるような有名人とかが「使ってます」って言うと人気になるのでしょうか。

ともかく、まずはブログサービスの提供者側として、投稿APIを公開する利点というものを整理してみたいと思います。

まず前提として、投稿API公開とは、標準規格(例えばAtomAPI、XML-RPC API) - などのオープンスタンダードに対応すればよい、という事。特別に「BlogWriteに対応」などする必要はありません。誤解されるケースがあるみたいですが、標準的規格に対応するだけで、どんなソフトでも使えるようになり、使うソフトはユーザーが好きに選べます。

投稿APIに対応すると良い事があるかもしれない点:

■サーバーの付加軽減と通信帯域の減少があるかも

APIを通じて投稿・編集されると、やり取りされるのは、XML形式のコンテンツなので、Webページに付属する画像データ、スタイルシート等の余分な行き来が減り、サーバークライアント間のデータ通信量が減少する傾向があります。また、オフラインで記事は編集されプレビューも出来るので、サーバー上でのユーザーの操作が減り、場合によっては負荷軽減に結びつく可能性もあります。

■ユーザーに選択肢を提供

人によってはエディタや通常のデスクトップアプリケーションで文章を書くほうを好む場合があります。また、ブラウザーで書いていて間違ってブラウザを閉じて書きかけの文章が消えたり、別ページへ移動して戻ったら文章が無い、などのアクシデントを防ぎ、ユーザーエクスペリエンスの向上を図る事が出来る場合があります。

■長く使ってもらえなければ意味が無い

ブログは日々利用されるもので、継続して使って(書いて)もらわなければ意味がありません。ユーザーに継続して毎日使いつづけてもらえるように、サクッと書けるデスクトップアプリの活用があってもよいでしょう。 もちろん、BlogWriteが持っている様々な機能(WYSIWYGモード、HTMLエディタ、雛型、表、画像サムネイル、ポップアップ....)等々の利用も出来るようになる、という利点もあります。

■オープンさのアピール、そしてサービス連携によるコミュニティの盛り上がり

ブログの定義はいくつかあると思いますが、オープンスタンダードに準拠していることが重要です。XHTMLとCSSで構成され、RSSを吐き出し、ブログのソフトもできるだけWebサービスを使って、そのAPIはオープンにする。そうすることで、誰でもそれらをつなげるソフトウェアを作ることができる。抱え込むのではなく、小さなデベロッパーが一緒にコミュニティーを作れるか、というのがブログの哲学ではないかと思います。ここ数年で革命的に伸びた新興企業の多くが、オープンスタンダードを用いて「自分」のためにシンプルに作る、というところからスタートし、そして成功しています。その意味では、韓国や一部日本のブログサイトは大企業が自分たちの独自技術で作ってしまっているので、旧態依然な感じがします。

 「Joiこと伊藤穰一氏、ブログの「今」を語る」 ITmedia:インタビュー

サービス間連携とコミュニティの盛り上がりの一例として、こうさぎなどのBlogPetによる投稿などが上げられます。

■万が一の時のバックアップ

サーバー上での問題が起きて、DB内の記事が消えてしまった、という事が万が一あったとしても、ユーザーの手元にコピーが残っていれば、ユーザーの怒りもそれほどではないかもしれません(保証の限りではありませんが^^;)。

■他のサービスに遅れない

あまり知られていないのかもしれませんが、かなり多数のブログ、特に有名且つ評価の高いブログサービスほど、APIに対応しています。投稿APIに対応していないと、一部ユーザーから遅れている、という評価を食らってしまうかも知れません。ブログのような(評価などの伝播が早い)サービスでは結構致命的かも...。

という事で今回は、サービス提供者にとって、投稿APIに対応し、本腰を入れる利点をあげて見ました。このような一見地味な機能も軽視せずに積極的、かつ本格的に対応していく、というのは大事だと思います。

 

追記:これとほとんど同時にPostされた「Open Data」に関する記事や、「Philosophy of Yes」も関連してきますね..。

投稿者 BlogWrite担当 : 13:09 | コメント (0) | トラックバック

2005年06月11日

XML-Atom

XML-Atom 0.12 - blog.bulknews.net
CPANに登録されている、AtomフォーマットやAPI用のPerlモジュールのXML-Atom。マルチバイト関連のバグが解消され、オリジナル作者(MTの人)から引き継いだmiyagawaさんがメンテする、とのことです。

TypePadやMovableType(あとLivedoor Blogも?)でのAtomAPI利用とかで、色々改善されるんじゃないかと思いつつ、XML-Atomモジュールに関するより多くの文書・サンプルとか色々期待しちゃいますね。

一つ現実的な要望なのですが、レンタルサーバーとかにもインストールできるように、XML::LibXMLやMIME::Base64 をはずしてファイルコピーでインストールできるPurePerl版のXML-Atomって出来ないんでしょうか。

AtomAPIを利用して、ちょっとしたサイト連携サービスを行いたい時、XML::Atomを使いたいと良く思うのですが、管理者権限のないPerl5.6とかのレンタルサーバーでは簡単に設置できないため不便に思っています。かと言って一からAtomAPIサーバーを作るのもひどく効率が悪く...。きっとこういった需要もあるのではないかと思いますが...って自分が使いたいとも言う...。

投稿者 BlogWrite担当 : 04:04 | コメント (0) | トラックバック

2005年03月17日

SOAPかREST、XML-RPC、WebDAV?

株価それぞれ下記のように推移しております。

Yahoo! Research Labs: Buzz Game - Market

本日の株価。

REST $17.95
SOAP $6.42
WEBDAV $6.58
XMLRPC $5.00


(ネタ)
http://www.ysearchblog.com/archives/000089.html
http://buzz.research.yahoo.com/

The Tech Buzz Game is a fantasy prediction market for high-tech products, concepts, and trends.
As a player, your goal is to predict how popular various technologies will be in the future. Popularity or buzz is measured by Yahoo! Search frequency over time.

投稿者 BlogWrite担当 : 21:11 | コメント (0) | トラックバック

2005年03月16日

AmazonのOpenSearchはRSS技術を元に

A9 OpenSearch

"We want OpenSearch to do for search what RSS has done for content."

OpenSearch is a collection of technologies, all built on top of popular open standards, to allow content providers to publish their search results in a format suitable for syndication. You can see how this works on A9.com.

コンテンツの配信でRSSがとても便利に使われるようになったように、OpenSearch APIは検索結果を配信、流用、他と連携して利用するためのものだそうです。
すべては、オープンな標準の上に築かれた技術を利用している、と。具体的には、RSS2.0の拡張として定義しているみたいですね。A9ですでに使われているとか。

詳しくは後ほど...。

追記:
「OpenSearch RSS format」は検索結果を返すフォーマット。RSSをXML名前空間で拡張したもの。
[OpenSearch RSS 1.0 Specification] サンプル

OpenSearch Description Document 1.0」は検索エンジンを識別し、フォーマットやサイト情報を記述するもの。検索サイトのどこかにHTTPのGETでアクセスできる場所に置いておく。具体的にどこだか仕様には書いていない。

OpenSearch Query Syntax 1.0」検索クエリのシンタックス、とっても簡単。


追追記:
重要な点を書き忘れ。RSS2.0をXML名前空間で拡張したものなので、既存のRSSリーダでの後方互換性は保たれます。つまり、何もしなくてもとりあえず今のRSSリーダー等で検索結果を取り込める、読める、という事です。もちろんもっと細かくコントロールしたければ出来る、という事です。AtomAPIの拡張もしかり。

投稿者 BlogWrite担当 : 10:11 | コメント (0) | トラックバック

2005年03月12日

Blogger AtomAPI 認証方式がWSSEからBasic Authへ

BloggerのAtomAPIの認証方法に変更があったようなので、BlogWriteからBlogger.comのブログにログイン出来ない場合があります。
Authorization: Status on SSL/Auth Basic?

認証方法が、WSSEからBasic Authになったようです。が...SSL通信はまだのようなので、ほにゃにゃらエンコード(笑)したユーザー名とパスが普通のHTTPで送信されてしまいます。まったくの平文のXML-RPCよりはマシというぐらいです。Blogger.comの意図がちょっと見えません...。

という事で、
BlogWriteアップデートVer.1.4.0です。


追記:
SSL通信が有効になったそうです。
エンドポイントも、
https://www.blogger.com/atom
に変更出来ます。
一、二週間したら、すべての
http://www.blogger.com/atom
へのリクエストは、https://...のSSLの方にリダイレクトされるそうです。


追追記:
Bloggerから「Blogger AtomAPI Documentation」公開
http://code.blogspot.com/archives/atom-docs.html

投稿者 BlogWrite担当 : 01:05 | コメント (0) | トラックバック

2005年03月03日

解説:Atom

技術評論社の編集者の方より寛大なる許可を得て、技術評論社「Software Design」2005年1月号 第2特集「次世代Webテクノロジ:Atom基礎講座」オンライン版を公開したいと思います。

解説:Atom - Atomとは何か: RSSやXML-RPCとの比較、そしてAtomAPIの使い方まで

どぞ。

#草稿を元にXHTMLを生成したので、タイポやバグってる所があるかと思います。おいおい修正いたします。なお、執筆は2004年の10月頃のため、一部情報が古くなっている個所がありますがご容赦ください。これもおいおい余力が出たら更新いたします。
もし、記事に間違い、勘違い、誤解ありましたらぜひツッコミ頂きたく思います。m(_'_)m

投稿者 BlogWrite担当 : 17:42 | コメント (0) | トラックバック

2005年03月01日

The Yahoo! Search Web Services - Yahoo! API

Miyagawaさんのブログ経由:Yahoo ready to open up their APIs

The Yahoo! Search Web Services
と題してYahoo!のコンテンツやサービスに外部アプリケーションからアクセスし操作するYahoo! APIが公開されました。XML Webサービスそれも、AtomAPIやAmazonと同じく

REST

素晴らしい。

詳細は調査中...色々面白いことが出来そう...。GoogleとAmazonだけでなくYahoo!も目が離せなくなってきました。(Yahoo!Japanはとっくに見捨てていますが...)


追記:こっちにもTB攻撃

投稿者 BlogWrite担当 : 16:31 | コメント (0) | トラックバック

2005年02月28日

不動産情報とXML

今日はちょっとお呼ばれして某大手不動産情報サイトさんの会社に行ってきました。
私ドモが一年以上前から業界に提案していた、不動産の物件情報のXMLによる標準化という動きが少し実現の方向へ向かいそうであります。

個人的には、BlogWriteでも使っている(技術評論社のAtomAPI記事にも書いた)Atom Publishing Protocolに不動産情報をのせてやり取りすればいいじゃんと思ってたりします。ハイ。

儲かりもしない事ですが、喜んで参加するつもりではおります。

不動産情報の流通という事で、現状の問題点:

■一般の不動産会社にとって各種情報サイトに物件情報を登録するのはかなりの負担。
結果として:
 ◇古い情報が残ったまま
 ◇タイムリーに情報が届かない
 ◇そもそも登録しないー>客が来ない

つまり、「一々サイト毎に一つ一つ物件情報を入力して、一々チェックしてられねーよ」という事であります。
でも、それでは客としても不便ですし、不動産業者も困る。

解決策:
  • 不動産物件の管理ソフトウェアのデータを情報サイトのデータを連携させればいーじゃんBlogWriteでやってるみたいに

よってXML(それ以外のフォーマットは考えられない)によりデータフォーマットを決定し、誰でも使えるように各種不動産物件管理ソフト等と各種不動産情報サイト等での共通の仕様として策定しようではないか。

という事だったりします。この仕組みはBlogWriteが記事を投稿、削除、更新するのとまったく同じ流れであり、項目は違えど、必要とされる機能は同じです。海外では1998年当時より不動産情報を扱う、XMLによる規格が既に存在していたりします。

また既に規格の仕様書として私の作成した(三日ででっち上げた)XMLスキーマとDTDの定義は済んでおり、後は使うだけなんですが、一人で使ってもしょうが無いですし、そもそもXMLは異種他社混合でのデータ連携に用いるものですから、皆で使わないと意味がありません。

そういった流れで、今回少し表立った動きが始まるのでは、と期待しております。

追記:XMLスキーマですが、某NTTホニャララとか某ホゲホゲで作ると数千万かかるとか....。何故にそんなにかかるのかとっても不明であります。

投稿者 BlogWrite担当 : 19:23 | コメント (1) | トラックバック

2004年12月06日

MSN SpaceでのBlog投稿API

マイクロソフト社に所属する、RSS Banditの開発者でAtomのMLで活発な発言もしているDare Obasanjoさん。今はMSN Space(MSが提供するブログ)のチームにいるみたいで、MSN SpaceでのBlog投稿APIを検討しているとか。

(以下超概要)
What Blog Posting APIs are supported by MSN Spaces?
Q.MSN SpacesではどのBlog投稿APIはサポートされてますか?
A.今のところどのAPIもサポートされてません。現在のXML-RPCのAPIではセキュリティ等がダメ。でも今検討中。例えば、

・Blogger/MetaWeblog API over HTTPS/SSL「Blogger/MetaWeblog API(XML-RPC)」
もっともツールが対応しやすい。
しかし機能的に足りない所がある。

・MSN Spaces specific API over HTTPS/SSL「MSN Spaces独自API」
独自APIではツールの開発者が大変である。
対応するツールも限られてしまうだろう。

・Atom API over HTTPS/SSL
予定では数ヶ月後に完成だが、予定が不透明である。
Atom Projectの予定に振り回されるのもどうか...

フィードバック歓迎....

だそうで...
どこも悩む事は一緒^^;

しかし、既存のXML-RPCのAPIでは機能不足、だから独自APIをXML-RPCで作る。そんな事をみんながみんな始めたら、破綻するのは分かりきっているわけです。
だからこそXML-PRCではなく、AtomのようなRESTで拡張性のある文書モデルを利用し、独自拡張機能はXMLに元々ある名前空間で対応しようという動きになった訳です。

ExciteさんとUbicastさんのやった独自APIはその破綻する方のやり方な訳です。

個人的に思う今現在のベストな対応方法としては、既存のXML-RPC APIにとりあえず対応し、独自機能についてはAtomAPIを待つ、という事だと思います。今検討されていらっしゃる方にはそうお勧めしています(例えば数ヶ月前にお会いした某社の方とかに...そろそろかな?)。

Atomはどちらにしても数ヶ月後になるのですが、なんにしてもDareさんこれまでAtomに結構貢献しているのだから、結果は見えてるような気がしないでもないですが....。どうでるか興味深く見てみたいと思います。

投稿者 BlogWrite担当 : 09:10 | コメント (0) | トラックバック

2004年11月07日

iアプリなXML-RPCクライアント

あそびをせんとやうまれけむ: 携帯電話が直接XML-RPCをしゃべる経由
YappoLogs: iアプリなXML-RPCクライアント配布開始しましたより引用、

Movable TypeのXML-RPC APIに対応したDoJaなクライアントの一般配布を始めました。

だそうです。(というか、よく見たらトラックバックもらっていた..orz)
ここでも話題になった、
Nokiaの携帯でAtomを利用したBlogへの投稿が2005年初めには可能に
携帯でAtomによるBlogクライアントの技術的問題点と新しい提案

携帯でブログを編集するiアプリ公開されたようです。面白そうですね。

で、あやまらなくてはならないのは、携帯でAtomするにはHTTPのヘッダが問題になるという事で、回避策があったけど改めて報告するといったきり、してなかった件です。ごめんなさい。

ということで、携帯でAtomする「MobileAtom」を紹介したいと思います。
「MobileAtom J2ME」携帯のJavaアプリでAtomAPIを実装こちらで、スクリーンショット付きの非常に詳しい解説があります。ソース付きです。

携帯でAtomクライアントを作成するのには、とっても参考になるのではないでしょうか。日本の携帯でも動くようになったら嬉しいですね。

投稿者 BlogWrite担当 : 10:08 | コメント (0) | トラックバック

業界標準を無視したエキサイトブログのXML-RPC

ついに、恐れていたことが現実のものとなってしまいました。

「旅行びと日記」日記: エキサイトブログがXML-RPC対応・・?より引用、

ubicast Bloggerがエキサイトブログに対応したとのこと。
で、ということはXML-RPC機能に対応してきたのかなと思いエキサイトでリリース文なんかを探すものの、発見できず。
「???」
という状態で色々調べてみたんですが恐るべきことが判明(萎・・

詳しくは上記リンク先を読んでいただくとして、何が問題かというと、
すでにある「業界標準」仕様を無視したプロプライエタリな独自仕様
混乱を避けようというBlog界の動きを完全に無視した動き

また、これらは混乱をもたらすものでしかなく、ユーザをも無視したものでもある、と言えます。

海外では、競合する各社でも開発者どうしが協力しあって、積極的に標準的な仕様を裁定しようとがんばっているさなかに、こういった独断的に協調や連携を阻害するような事をすると、せっかくのBlogにおける利便性が損なわれることになります。

RSSやAtomにしても、標準仕様というのがあって、みんなが同じものを使えるからこれだけ便利になり、種々のツールやサービスが生まれました。

オープンな標準と相互運用性がキーなのです。

市場においてある程度の位置にある一社がそれを無視した動きをするのは、おそらくは無知からきたものだと思われますが非常に残念であります。

おそらく、エキサイトとubicastさんの中の方たちは、Atom APIというものをご存知ないのかもしれません。これは、私もいままで積極的に情報を発信してきたつもりですが力不足の面があったかもしれません。また、Atom APIに関して日本語の情報がまだ少ないという事もあるかもしれませんね。

そういう事もあり、ちょうど今、技術系の雑誌にて、Atomについて記事を執筆させていただいています。ここにて、XML-RPCとAtomAPIについて詳しく書かせていただきました。XML-RPCにおける混乱を懸念していましたが、間に合わなくて本当に残念です。

投稿者 BlogWrite担当 : 09:29 | コメント (0) | トラックバック

2004年07月23日

Atomプロトコル (Atom API) の可能性:不動産業界での例

The Atom Publishing Protocol(以下Atom API)を現実的な視点から少し考えを文章にしてみたいと思います。

Atom APIコンセプトが実際に有用であり、単なる卓上の話ではない事は、Atom APIの'Proof of Concept'でもあるBlogWriteが実証していると思います。

元々、主にBlogなどでの利用を想定して裁定が進んできたAtom APIですが、現在、用途を限定しない方向にシフトしています。
さらにXML-RPCと違い、Atom APIを利用するとXMLの利点をフルに活用した拡張を行なう事が容易になります。Atom APIのコアの部分とその拡張性を生かしてどんな事が出来るか、を考えました。

不動産業界

各不動産会社はインターネットの各種サイトに日々物件情報を掲載しています。空き物件は日々入れ替わり、毎日のようにウェッブ上の物件情報を修正する必要があります。さらに、一つの物件につき多数の項目が存在し、掲載するメディアも幾つものサイトに渡るため、その負担はそこそこのものといって構わないでしょう。

では、実際にはどのようにしているのか、というと...。

ある社は印刷された紙媒体を専用業者に委託してウェッブに掲載させている。自社ウェッブサイトがない、またはあまりWebの知識がない企業。大多数がこれである。更新が遅いため掲載物件がうまってしまった時など致命的である。

または、管理物件を管理ソフトを使いデータベースで管理しているケースの場合、ソフトからCSVなどをFTPでソフト専用のサイト等に物件情報を登録している。汎用性やソフト間の互換性はまったくない。結局多数のサイトに掲載するには、ブラウザベースの登録フォームに決まりきった多数の項目を毎回ひたすら手で入力するのである。


もしこれが、物件情報を管理する管理ソフトウェアと不動産ジャパンなどの全国的な不動産物件検索サイトがAtom APIを通して連携したらどうなるだろうか。

不動産会社は自社で利用している管理ソフトウェアからボタン一つで好きな物件情報を全国レベルのサイトにモノの数秒で簡単に登録できるようになるはず。

また、Atom シンジケーション フォーマット で物件情報をエクスポートすれば、XSLTなどを利用して簡単にWebと連動した印刷媒体も作成可能になるのです。

さらに、不動産検索サイトにおいて、検索条件を登録しておき、その検索結果をユーザーがAtom シンジケーション フォーマットで取得できるようにすればユーザーはRSSリーダー等を使い特定の条件の物件だけをタイムリーに取得できたりするのです。

では何故そういった動きがないのか。以下のリンクが参考になるかもしれない。


もしも天気予報がXMLだったら - その1 XMLとは?

もしも天気予報がXMLだったら - その2 できない理由


不動産業界でも実体は似たり寄ったりで、日本の構造的な壁がまた浮上してくる。

さらに、本家Yahoo!の技術力とブランド力だけのYahoo! Japanにとっては不動産コンテンツ掲載は重要な収入元であり、Atom APIやXMLによって一般にもたらされるパワーを恐れその利用に反対している。 またイサイズなどを運営している情報流通大手リクルートは自社内ネットワークの情報一本化に手一杯であり、不動産情報流通に新たな技術を持ち込む余裕がないという。

そういった旧弊を打開するには、やはりライブドアのようなヤンチャ者が必要なのかもしれない。

投稿者 BlogWrite担当 : 20:06 | コメント (0) | トラックバック

2004年05月18日

Atom API vs XML-RPC

Blogエディタを開発中であるわけなのですが、 (このエントリーもそのBlogエディタで書いているのは秘密です)結局AtomAPIではなく今の所はXML-RPCでいこうかと思います。 本来はAtomAPIで行きたかったのですが、これや諸般の理由により AtomAPIの実装はとりあえず断念します。

以降、何かの足しになればと思い公開するものであり、技術的詳細やら長話に興味がない方には申し訳ありませんが あまり興味のある話ではないかと思いますのでご了解ください。 (とか言いつつ、Blogエディタのテストがしたいだけじゃないのかという話も聞こえる)

改めてですが、Blog本体と通信し更新などの処理を行なう方法で今現在一般的なのは、XML-RPCと言われるものです。 大抵の(と言っても少ない)BlogエディタはXML-RPCで実装されていて、クライアントソフトウェアーサーバー間の 通信にXML-RPCが用いられています。

しかし、個人的に前からどうせ作るのならXML-RPCではなく、Atom APIでと思い一人去年から騒いで (..) (..) いたのには理由があります。

Blog関連に絞ったウェッブ上のリソース管理パブリッシングプロトコル(長い)として非常に強力であると認識したと同時に 現行の方法では解決できない問題を幾つか解消しつつ新しい機能を実装できるからです。 以下、つらつらとAtomAPIについて、またXML-PRCとの簡単な比較などつらつらと書いて見ます。

国際化について

・XML-RPC
ちょっと前まで、仕様により文字列に日本語などのマルチバイトを使用出来なかった。 また、日付のタイムゾーンの指定が仕様で明示的に禁止されているため、混乱が起きやすい。
・ATOM API
多分問題なし。

拡張性について

・XML-RPC
データ型の規定が存在する。利用できるメソッドを指定できる。 そのため、汎用性があるが、拡張性に乏しい。 元々は名前が示す通り、リモート呼び出し手続きに利用される。
・ATOM API
ウェッブコンテンツ更新等のために今現在裁定されつつある新しい規格。 名前空間を利用したりして、拡張するのが容易。

セキュリティについて

・XML-RPC
セキュリティ特に決められていない(?)。 今現在、Blogなどを更新するケースでは、パスワード自体が(暗号化せずに)平文で送信される。 (ブラウザーでの更新も同じ)
・ATOM API
SHA1で生成した、160ビットのハッシュ値を送るため安全性が高い。 生成されたハッシュ値からパスワードを得るのは現在の所、不可能。


より細かい比較、というかAtomの利点については、本家SixApart社のページ(英文)を参照ください。 Why We Need Echo (EchoとはAtomの旧名)

付け加えるべき利点といえば、もうだいぶ解消されてきた模様ですが、 TrackBackの文字化けも、対症療法ではなく原因から根本的に解消されます。

ずいぶん前に書いたATOM関連のエントリー
Atom and Its API

更新PingやTrackBackPingが実装されてればそれでBlog完全対応!で終わらせられるのがちょっぴり 残念で、出来れば多くのBlog関連のサービスやツールが、少なくともXML-RPC、できればAtomAPIの実装にも 力を入れていただきたいと思うこのごろでした。




投稿者 BlogWrite担当 : 17:55 | コメント (0) | トラックバック