Nokiaの開発者であるBen Barnard氏とFelix Leipold氏はGOTO Berlin Conferenceで"Building, running and promoting a public API"と題して、パブリックなウェブAPIの設計開発の経験を発表し、APIは自然なユーザインターフェイスを持っておらず、その結果、扱いにくくなっている、と発表した。
彼らが提供しようと開発しているのは、ホテルなど場所を検索するためのAPIで、複数のバックエンドシステムからデータを検索し集約し、統一したビューをクライアントに返す。内部のクライアントも外部のクライアントも利用する。
Felix氏が指摘したのは、APIは明確なユーザインターフェイスを持っていないということだ。例えば問題が起きているとき、実際何が起きているのかを理解するためには、リクエストはとても抽象的だ。リクエストのHTTPヘッダとボディがあり、レスポンスにもヘッダとボディがある。デフォルトではすべてのレスポンスはJSONを返すので、ユーザフレンドリな方法でレスポンスを見るために、コンテンツネゴシエーションを追加し、ブラウザからリクエストを受けた場合はhtmlを返すようにした。その後、エンドポイントごとにひとつのフォームを作って、データ入力からのリクエストを受け付けられるようにした。最終的にはAPIのチェックを単純にしてくれるツールであるPlaygroundを呼び出すためのUIを作った。
意図した通りに動作しなかったのは後方互換性を保証するためのテストの方法だ。APIの変更に対応できないクライアントを支援するため、すでにAPIを利用しているクライアントがAPIの変更によって悪影響を受けないようにする必要がある。彼らはこれを実現するためにConsumer-Driven Contracts、CDCを試した。クライアントがAPIに対する予測にしたがって小さなアプリケーションを作り、そのアプリケーションでAPIを検証する方法だ。しかし、クライアントにとってはそのようなアプリケーションを作るのは難しかった。また、偽陽性の問題もあった。問題がなくてもテストに失敗してしまうのだ。また、偽陰性の問題も発生した。クライアントに問題を引き起こすはずの変更が問題を起こさなかったのだ。結局、CDCでは望んだ通りの信頼性を確保できなかった。
より信頼性の高い方法は実際の運用環境のアクセスログから情報を入手して新しいバージョンのAPIがリクエストを問題なく処理できているかを確かめる方法だ。彼らは、リクエストされたURLとリクエストヘッダをログから採取して、ツールをリクエストを、運用環境と新しいバージョンのAPIに対して再実行し、レスポンスのJSONを自動と手動の両方で比較した。
Felix氏の説明では、バックエンドサーバへの大量のリクエストの中から特定のリクエストを追跡するのが難しかった。彼らはリクエストにパラメータを追加し、ログを出力したり、フロントエンドのサーバが検索したりログ出力できるボディに追加の情報を付加することで、リクエストを処理できるようにした。この方法はかなりうまくいった。
GOTO Berlin Conference 2013はベルリンで初めて開催されたGOTO Conferenceで420名が出席し80人が登壇した。