Web APIの最近のブログ記事
ZIGOROuさんの記事を読んで知った通称SREGを、先日作ったMT 4.1のOpenID 2.0 OPプラグインに実装してみた。requiredとoptionalの違いとか、ユーザーが何を送るかを選ぶ機能とかを実装しないといかんな。
で、テストしようと思ったんだけど、どのRPがSREGを使ってくれるのかわからないので、とりあえずMTの標準のOpenIDコメント機能にもSREG機能を使わせるようにして、myopenid.comでテストして、んでローカルでテストしてみた。とりあえず動いた。
SREG使ってるRPを知ってる人教えてください。
を書いた。
http://code.sixapart.com/trac/mtplugins/browser/trunk/openid2-server
ちょっとまだ迷ってるところがいくつかあるのだが、まあまあ晒してしまえという勢いでコミットしたので、バグだらけでご勘弁。新しいNet::OpenID::Serverのやつも必要です。
で、僕もYappoさんの丁寧な解説とコード、それにid:lopnorさんのコードのおかげで楽できました。ありがとうございます。
http://fastladder.com/
http://lopnor.homeip.net/~danjou/authenopenid/
http://pibb.com/
http://twitwi.tw/
http://limilic.com/
で試したんだけど、pibbはhttpsが必要でこのホスティングに入ってないので、ログイン完了後の画面に遷移できなかった。twitwiはopenid2.local_idに無難なURLを指定すればログインできたけど、指定せずにmt.cgi?__mode=openidみたいなidentityで行くとエラーになった。limilicもログイン完了後のリダイレクトでエラーになった。たぶんこっちのコードが悪いんだろうけど、どこを直すかわからないので誰かが教えてくれるのを気長に待つことにします。
はてなスターをMovable Typeで表示する方法はいろんな人が書いてるけど、やっぱHTMLタグ書くのはMTらしくないだろーってことで、今日のhack-a-thonでMTHatenaStarを書いてみた。
出力するHTMLについては、「さりげないはてなスター」に書いてあったHTMLを丸ごといただきました。ありがとうございます。
使い方
- はてなスターにブログを登録し、トークンを入手する。
- プラグインフォルダにMTHatenaStarフォルダを丸ごと放り込む。
- プラグインの設定画面で、１で取得したトークンを入力し、保存する。
- はてなスターを表示したい場所に<$MTHatenaStar$>を書く。ただし、MTEntriesのコンテキスト内（つまり、MTEntryTitleとかを使える場所）に。
- 再構築（ダイナミックパブリッシングなら不要）。
- はて☆スタ。
はてなスターを表示する場所に<script>タグも一緒に表示されちゃうのがいやなときや、はてなの指示通りに<head>の中に書きたいときは、<$MTHatenaStarScript$>タグを使えば、<script>だけを別途出力できます。ただし、処理の関係で<$MTHatenaStar$>よりは前に置く必要があります。
もちろんダイナミックパブリッシング対応だよ！
Amazon FPSという名前になったらしい。
http://www.amazon.com/b/?ie=UTF8&node=342430011&no=3435361
いわゆるいつものSOAPまたはXML over HTTPで、自分のサイトにAmazonでお支払いボタンを付けられるらしい。co-branded UIてのがあるから、たぶんお客さんが自分のサイトからAmazonへ遷移しても、自分のサイトのロゴなんかを表示して、Amazonと一緒にやってます的なUIにできるような気がする。
おめでとうAWSチーム。
ってどこに出るの？
Web Services Coming To Twitter
How basic is Twitter?
TwitterをMechanical TurkとかQuestionsとか人力検索とかのコマンドシェルにするとおもしろいとか。
いっそ
@perl -wc mydumbperlscript.pl
とかやると添削してくれるとか。
こんなおいしそうな議論をしていたとは、さっき飯食ってたときはぜんぜん知らなかったな（苦笑）。アンテナが下がってる。
naoyaさんの文章を読んでいてふと疑問に感じたのが、APIというときのIと「インタフェース」と書いたときとで、それぞれ異なる意味で言葉を使っているように読めるってこと。miyagawaさんのエントリのタイトルが「API, UI as Commons」と2つのIを並列して書いているのと並べて読むと、そこんとこを深読みしちゃうなぁ。
Catalyst の View::JSON とかは渡したデータ構造が勝手に JSON になって Web API になりますよ、というものだけども、これだけだとまだ開発者は「どういう API を持たせて、どういうデータ構造を返して」というのを自分で考えないといけない。なのでインタフェースに制約が欲しい。
APIというのはアプリケーションに対してサービスが公開するプログラミング用のインターフェイスだ。ViewがJSONになったからってそれがサービスが公開するインターフェイスになっていなければ、それはapIではない。それは愛じゃない。
Gが認証APIを出そうとしている。今のところデスクトップにインストールされるアプリケーション用のAPIだけが公開されている。EメールとパスワードをPOSTで送るというそのまんまじゃん的仕様が基本で、唯一少し差を見せるのが、連続的にアクセスされている場合には、エラーとともにCAPTCHAを使って人間が使っているのかどうかを確認するという機構を備えているところ。Web APIのほうはどうなるのか（4月下旬公開予定って書いてある）ね。
まあインストールした時点でそのアプリを信頼しているのだからパスワードを教えるくらいなんでもねーだろ、って話なんだろうけど、なんかさー。インストールしたアプリケーションが「そのアプリケーションで使う」パスワードを覚えるのはなんでもないけど、インストールしたアプリケーションに、「メールでもAnalyticsでもカレンダーでもなんでもかんでも、しかもそのアプリケーションでだけではなくブラウザだけでも利用できるパスワード」を教えるのってやっぱ抵抗あるでしょ普通。ないの？あ、そ。
Carson Workshops SummitのMP3を聞いているんだけど、パネルディスカッションが面白い。最初のほうで認証APIの話になって、MSがPassportの反省を活かしてやってくるぞ、とかOpenIDとか面白いよねとかいう普通の話が出ていたと思ったら、「っつかそれ大事か？」みたいなことを言ってる人もいる。「どうせみんなパスワード同じの使ってんだし、覚えさせてるんだからサインインなんか問題じゃないだろ」とか、「登録画面がめんどくさいのは問題だ」とか、「メールだけ入れさせて、メールを送って、そこからクッキーにつなげられれば認証はメールのほうに任せられるんじゃねーの」とかいう感じで、認証APIなんか別にいいよ、って雰囲気もあるようだった。ちょっと誰が誰だかわかんなかったんだけど。
まあ認証API出してよ、って今日も某社の某氏にダベり半分お願いしてきたくらいで、今のところ考えが変わってきたわけでもないんだけど。Amazon S3はAmazonの認証を使うんで、例えばS3をブログのバックエンドにしようとか思ったら、ユーザーとかコメンターとかをAmazon.comのアカウントにしなきゃなんなくて、これはこれでウザいね。Amazon内ですら統一されていないのに、他社のIDをサポートするわけにもいかないし、OpenIDもちょっと目的と違うし、という感じ。認証界隈はまだまだ考えることがいろいろありそうだ。
Carson Workshops Summitのほうに戻ると、聞いた限りではDel.icio.usのJoshuaの話が面白かった。ほかにFlickrのCalと37signalsのDHHのも聞いたんだけど、Calの話はどっかで聞いた（面白くないわけじゃないけど）感じで、DHHのほうはどうもなんだかウーン？って感じだった。Joshuaは最初タグについてしゃべってくれって頼まれたんだけど、「それはしゃべる気にならなかったから、他のことをしゃべるよ。」って言って、Del.icio.us関連の苦労話とか学んだことみたいなのを一生懸命しゃべってる感じだった。
やっと出た。Simple Storage Service略してS3。Mechanical Turkが野心的ならS3は当然の成り行きといえるプロダクト/サービスだろう。Readonlyのデータならチープなハードウェアでいくらでもリクエストに応えられるようになった今、次に必要なのはExtremely Writableなサービスでどうやってスケールさせるかという話だ。
