先月の出張スケジュールからお察しいただけるかも知れませんが、10月はカンファレンスシーズンの最盛期でした。毎週のようにカンファレンス (翻訳業界向けが2つ、テクノロジー関連が3つ) に出席し、最新の情報収集又は発表を行なうという日々を送りました。

翻訳業界向けカンファレンスに関する当社の所見については、弊社のジェシカ・ローランドが見事に総括をしてくれたので、私はAPIに関連する2つの人気イベント、「APIワールド」と「APIストラテジー&プラクティス」についてご紹介したいと
思います。各イベントを合わせて、4つの要点を持ち帰ってきました。

• APIドキュメンテーションの世界に、いくつかのトレンドやベストプラクティスが現れている。
• 以前と比べより多くのAPIをテストしたりデバッグをサポートしてくれるツールが存在する。
• 第三者APIの統合に向け、教育とオンボーディングプロセスの簡素化に的を絞ったツールが出て来ている。
• 技術とチームの両方を調整するのは大変なことである。万能なアプローチはなく、プロセスやアプリケーションは成長段階によって変化する。むしろ、調整の難しさはギアチェンジするタイミングを把握する点にある（クラッチを使わないでギアチェンジをしてみた事はありますか？とても難しいですよね）。

これから簡単にご紹介する注目すべき点によって、現代のAPIの幅広い展望の証明という意味で参考にしていただければと思います。APIがどのようにして価値を生み出せるかという課題は大いに関心を集めている一方、「開発者の支持を得られているケースはかなり稀だ」が現状となっているようです。私はまったくその通りだと思います。開発者に対して最もうまくコミュニケーションがとれているプラットフォームが一番大きな成功を収めるでしょう。

話題を呼んでいるAPIドキュメンテーション関連のベスト
プラクティス

APIを使って作業をする開発者に対するコミュニケーションにおいて欠かせない重要な要素は、ドキュメンテーションです。apiary.ioの創業者であるジェイコブは、「APIはデータに対するUI」と語りました。確かに、あることが非常に簡単にできると示したい場合、取扱説明書が必要ないことより良い方法はあるでしょうか?

そんな理想の世界に到達する助けとなるかのように、 APIドキュメンテーションが標準化に向かっていることを示唆するツールの数は増えているようです。API導入に沿ったドキュメンテーションのプロセスを簡略化するため、エンドポイントの記述言語（JSONなど）がベストプラクティスの1つとなりつつあるのは間違いありません。いまだに明らかな勝者が現れていないうちに、選択肢が増えるのは嬉しいかぎりです。

API デバッグツールの急増

カンファレンスで得た最も面白い知識の1つと言えば、テストおよびデバッグ用ツールがやたらに多くあることを知ったことです。APIでバグを見つけることについては、Twilio、IFTTTのジョン・シーハン、現在はRunScopeで有名な彼の言葉が最もうまく表現しているでしょう ー「… API をぶっ壊す一番の方法は誰かに使ってもらうことだ」。確かに、これは弊社も体験済みです！

 もちろん、お客様は予想外のトラブルを通常歓迎しないものです。ですから、できる限り社内でテストを行うためのツールの候補をご紹介します。新種の便利なツールが見つかると思います。

• requestb.in — クライアントが生成しているものを参照、特にwebフックのデバッグに便利 。
• ngrok.com — webフックのデバッグ用にローカルマシンにパブリックURLを
  付与。
• mitmproxy.org — 作成した API とクライアント間においてHTTPトラフィックで相互作用するのに最適。
• hurl.it — コマンドラインでコーディングしない場合、ブラウザ経由でHTTP要求をシミュレーション。
• PonyDebugger — iOSトラフィックをデバッグするブラウザベースの素晴らしい方法。Squareチームが構築。
• frisby.js — node.jsベースのエンドポイントのテスト。
• VCR — スピードに焦点を当てたHTTP相互作用テストパッケージの作成。
• mocky.io — apiary.ioの模造版。

ツールやライブラリの数が増えているもう1つの領域が認証で、特に OAuth (オーアース) 向けに増加しています。WebShellではOAuthの解決策を提供していますし、Mashapeでは、OAuthバイブルにおいて複雑な規格の素晴らしい説明やguardian.jsにおいて独自の解決策を提供しています。また、Mashapeではさらに一歩踏み込んで、unirestでHTTP要求ライブラリの独自のバージョンまで提供しています。

万全なエコシステムの基礎は優れたコミュニケーション

APIエコシステムを育てるうえで最も重要な要素は信頼であり、この信頼はコミュニケーションを通して確立されるものです。開発者は、最新の情報がどこで入手できるかを明確に知り、迅速に判断を下せるだけの十分な知識を身につけなければ
なりません。

しかし、ProgrammableWebの元エディターであるジョン・ムッサーの指摘によれば、 API がうまく動作しないとき、プラットフォームには開発者コミュニティに通知する多数の手段があります（たとえば、ブログや熱心な開発者フォーラム、ソーシャルメディア、チェンジログ、メール通知、GitHub、APIドキュメンテーションなど、例を挙げればきりがありません）。コミュニケーションするための媒体があまりにも多すぎて、サービスプロバイダと開発者の双方がうんざりするほどです。

従って、万全なAPIエコシステムを実現するには一貫性と透明性が必須です。この段階のコミュニケーションの重要性を明確に示した最高のプレゼンテーションの1つがアダム・デュバンダーによるものだと思います。3つの「C」でAPIの魅力を表現していたのです。その3つの「C」とは Clarity、Cost、Community (明晰さ、コスト、
コミュニティ) です。

Clarity (明晰さ): 認証に関する業界のベストプラクティス (LinkedInのOAuthテストコンソールなど) を公開したり、別のものをサポートしながらどのクライアントライブラリが公式版であるかを明確にします (Twilioがその例)。アクセシビリティと呼んでもおかしくないぐらいです。

Cost (コスト): 開発者がどのような制限（レート制限、使用制限、料金ブランなど）を認識しておくべきかを知らせる働きがあります。例えば、GoogleのAPIコンソールを見てみると、一貫した開発者コミュニケーションと透明性を
備えています。

Community (コミュニティ): APIに取り組む開発者に対する報酬メカニズムを持つことがより一層採用を促進します。Yellow API はアプリギャラリーを持っており、それがYellow Pages にとって良い結果となっています。TwilioconやEvernoteのECのようなプラットフォームに焦点を当てたイベントや、Hacker LeagueやChallengePostのようなイベントコーディネーションサービスも、開発者にちょっとしたケア・やる気を与える方法を示す好例です。

まとめ

APIのような一見ありふれたものに関して数多くの活動や支援が存在することを知るのは嬉しいものです。でも実際のところ、これはサードパーティの採用を推進する際に、APIを取り巻くエコシステムの役割がいかに重要であるかを裏付ける証拠にほかならないのです。

そういう意味で、つい最近弊社はイベントコミュニティのページと、非常にシンプルなGengo APIの簡単入門ガイドを公開しました。アクセシビリティ、透明性、そして開発者とのコミュニケーション（「Developer love (開発者へのケア）」）を高めて、Gengo API開発者コミュニティとの関係をますます向上させていけるのを楽しみにしています。