WebAPI利用サービスの企画から運用で考慮すべきこと

Question

WebAPIの利用は割りと頻繁に使用する技術であるにもかかわらず、網羅的に整理できておりませんでした。
ただ、私の考慮できる範囲は、個人商店レベルなので、きちんとした業務レベルで利用されている方々の知見をいただければと考えました。

私の考えるポイントは以下のとおりです。（思いつきで書いてます。すみません＾＾；）
不足点の指摘やご意見をいただけないでしょうか。

企画

・そもそもAPIに依存するコンテンツで良いのか？
API提供元の都合次第でコンテンツがなくなる可能性を考慮しているか？

・APIの利用規約に反する内容になっていないか？
利用目的の制限や利用範囲の制限に抵触していないか？

設計

・アクセス頻度は適切か？
APIの制限を超えるものになっていないか？

・APIのドキュメントは一通り目を通したか？

・エラー処理が適切に設計できているか？

・使用するライブラリがあれば、その実績や機能に問題はないか？

構築/テスト

・実装としてアクセスは適切になっているか？
キャッシュを取るとか。逆にキャッシュを消すとか。

・使用するライブラリの仕様を把握しているか？
おかしなアクセスや内部でのループ処理が入っていないか？
エラー処理は適切か？

運用

・エラー等の監視が必要十分に出来ているか？

・APIの仕様変更やセキュリティ情報に定期的にアクセス出来ているか？

ある程度ご意見いただけたら、Qiitaとかにまとめようと思っています。

Answer 1

API というと漠然としすぎていて、まとめるにも難しくないでしょうか？
Web アプリケーションのマッシュアップで API を使う場合の話だと思いますが、以下の二種類にわけませんか？

• API提供側が個人ごとにサービスを提供していて、呼び元サービスにログインしているユーザと同一人物としてAPIにログインする→複数のサービスを連携させるワンストップサービスを提供する
• API提供側が地理情報や消費統計情報などのデータベースを提供していて、呼び元サービスのIDでAPIにログインする→それらの情報を統合して、さらに便利な形態で情報を提供する

両者で契約形態やエンドユーザとの責任分界点なども異なってくると思います。

Comments

[退会済みユーザー]

（タイトルは修正しました。）
APIというくくりは漠然として難しいかもしれないですね。ちょっと思いつき質問になりすぎたかも。。。
上げていただいた2点の境界も結構曖昧だと思うので、分離も難しいように思います。

契約形態やエンドユーザとの責任分界点なども考慮ポイントとして重要ですね。
ご指摘ありがとうございます。