APIを公開するということの意味と価値と意志と…。

アプリにしろWebサービスにしろサーバーサイドが存在しているサービスは多いだろう。今日はそんなサービスがAPIを作成して公開することについて話してみたい。

エンジニアに限らずプロデューサーやディレクター、デザイナーなど開発現場に属している方は是非一度APIというものについて考察していただきたい。これがそのキッカケになれば幸いだ。

今日のネタ元はこちら

UberがAPIを公開―TripAdvisor、UAなど外部アプリ内からUberが呼べるようになった

先週、われわれのJosh Constineは「Uberはサードパーティーのアプリ内からUberの車を呼べるようにAPIを公開する準備をしている」という記事を書いた。今日（米国時間8/20）、Uberは11社のサードパーティーのパートナーに対してAPIを提供したことを発表した。

これをみて自分は感激した。Uberは今までも様々な施策などで幾度となく驚かされていたけれど、今日この記事を読んで驚きが感動に変わった。Uberがみていたものの片鱗が垣間見れたからだ。

はじめに言っておくが、規模やサービスのコンセプトなどによってはAPIの公開は悪になる可能性はある。それもあってなのか不思議なことにAPI公開の価値を言及する人は多くない。

それでも敢えて言いたい。API公開にはコストや負荷以上に価値がある場合があると。

サービスが発展途上にあるのならば、より多くの柔軟な発想に触れるべきだ。最小構成のチームで開発している場合、圧倒的にリソースが足りていないことを再認識すべきだ。自分たちはコア部分に専念する。という意味でも。

自身のサービスのことを想うのであれば、親は過保護しぎてはいけない。インプットもアウトプットも存分にさせるべきだ。

後回しになりがちなことだし、とても大変なことだが、幸せにはなれる。サービスが大きくなってからではそれこそ手が付けられないモンスターになってしまっている場合もあるだろう。

公開タイミングやその内容は、サービスの状態に合わせて変更していくという前提条件を忘れずに。

いざ公開する前に、以下の点には注意しておいたほうがいい。

完全公開を悪とは言わないが、登録制をお勧めしたい。ある程度コントロールできるようにしておかなければ、それこそ何かあった時の対処法が継続か停止という2択のみになってしまう。

これは負荷やコア体験部分に関してである。大抵の場合、緊急時におけるAPIの優先度は高くない。

影響し合うような設計は避けて、しっかりとお互いに独立すべきだ。

サービスの可能性を妄想するのは単純に楽しい。最初は遊び感覚でやってみるといいかもしれない。ぜひ試してみてほしいですね。

Dayoneからの投稿3日目