Webサービスを成功に導くAPIの公開方法

私もCSSEZというWebサービスを公開・運用しているのですが、APIの公開方法と公開情報の最適化に頭を悩ませています。どのような情報をどのような形で公開するのが良いのか。そして、それをWebサービス全体としてどのように有効利用できるのか。

そのヒントとなる記事がありました。Social Networking.jp経由で知ったのですが、Twitterの共同設立者へのインタビューで、そのTwitterの方はTwitter　APIへのアクセスがウェブサイトのアクセスの軽く１０倍はあると話しています。

---

---

the API which has easily 10 times more traffic than the website, has been really very important to us.
Read/WriteTalk » Blog Archive » Biz Stone - Co-Founder Twitter

そして、API派生のサービス群のおかげでTwitterが非常にシンプルなサービスを維持できていると語っています。

そこで、考えました。

Webサービスを短期間で爆発的に認知してもらうためには、サービスとしてのシンプルさというか単純さというものは必須なのではないかと。そして、サービスとしての高機能化はAPIの公開とその利用によって成されるべきなのではないかと。

APIを公開しても、誰も利用してくれそうにない？じゃあ、自分で利用すれば良いじゃないですか。

開発者自身のためのAPI公開。そういう選択肢もありだと思います。

まあ結局のところは、サービスのモジュール化とコンセプトは同じようなものですが、それをWebサービスの場合もコア機能と周辺機能をAPIによって分離できるのではないでしょうか。

Webサービス本体をコア機能のみのシンプルな構造にしておけば、サービスドメインも明確になりやすいですし、新規訪問ユーザーへの訴求率も高いと思います。

CSSEZの場合、下手に高機能にしてしまったために、アピールポイントが複数できてしまい、結果として訴求するポイントが曖昧になっているような気がします。そこで、CSSEZ自体の機能をデザインの作成とダウンロードのみに絞ってしまおうかと思います。

そして、デザインの検索はAPIで提供。デザインギャラリーのようなものを外に作るといいかもしれませんね。それとは、別に申請ベースのデザインギャラリーを作ることもできますし、幅が広がると思います。

名前も変えちゃおうかなぁ。ブログデザイナーとかブログデザインジェネレータとか、ブログテンプレートジェネレーターとか、ブログスキンメーカーとか、ブログテンプレート作成ツールとか、もうちょっとブログに特化したアピールの方向で。

Webサービス本体をコア機能のみに絞り、周辺機能をAPIによって利用する。これはサービスの収益化にもメリットは高いはずです。さあ、いかがでしょう。