10 Common Mistakes Made by API Providers - ReadWriteCloud の要訳というか超訳。

1. いつも全部が正しく動作していると仮定する

データベースのエラーやバックエンドの処理遅延などによって API の出力がおかしくならないように、 ユーザに提供する前に依存性を確認して、APIがどう動くかを確認すること。開発者(APIのユーザ)は stack traceなどではなく、正規のレスポンスフォーマットでエラーコードなどが返ってくることを期待している。

2. お粗末なコミュニティ管理

開発者を引きつけるには、コミュニケーションを取って彼らの役に立つこと。開発者をパートナーと 考えて対応する。

3. API ビジネスプロセスの規模を予測しない

規模が小さいうちは、ガバナンスの必要性は少ないが、API のトランザクションの規模が大きくなると、 ファイナンスや法務にとっても重要な問題になってくる。

4. API をウェブサイトと同じドメインに置く

ウェブサイトと API それぞれのスケーラビリティを別個に扱えるように、別のドメインにする (twitter.com と api.twitter.com のように)。

5. 実際の環境でテストしない

もし、ウェブサイトがその API を使っていないなら、API を使ったサンプルアプリケーションを いくつか作ってみること。そうすることによって、API で取得できるデータの内容(組み合わせ)が 適切かどうかを知る事ができる。API を使ってあなたのウェブサイトを再現できないとしたら、 その API は修正する必要がある。

6. 悪質な挙動を想定しない

意図的なもの (頻繁なリクエスト、渡される JSON や XML データによる攻撃、SQL インジェクションなどのテクニック) や、スケーラビリティに関係するものを考慮して設計する。

7. ブラックボックステストをしない

アップデート時にはウェブサーバの設定変更等も行う事があるので、ユニットテストだけではなく end-to-end のブラックボックステストも行うこと。

8. API をコアビジネスと認識しない

成功したメディア、オンラインショップ、ウェブ関係の会社は、しばしばそのトラッフィックの 50% 以上が API 経由になっている。従って API を製品の 1 つとして扱うこと。

9. API について役員レベルのマネジメントを行わない

他の新規プロジェクト、ビジネスや技術と同じように (API についても) 理解と明文化された ゴールや評価基準などを持ち、各部署レベルの目標に落とし込んでいく必要がある。

10. エラーを tunneling する

よくあるのが、エラーなのにレスポンスコード 200 OK で返したり、すべてのリクエストを GET, POST で処理したり (PUT, DELETE を使わない)、ユーザに content-type を指定させない、など。