今回はAPIを利用する側の視点で見ていたいと思います。APIを使わずに構築されることの方が減っている現在、特有の注意点があるとすれば何でしょうか。
削除系の取り扱い
APIではその命令を実行すればそのまま処理されます。コンピュータ上で自動処理される場合、あっと思った瞬間にはすべて処理が終わってしまっている可能性がありますので。データの参照、追加処理についてはさほど大きな問題にはなりませんが、更新や削除処理については十分に注意して開発すると必要があります。
間違って不用意なデータの更新、削除を行わせないためには権限管理が欠かせないでしょう。また、バックアップが取れるAPIが提供されているものを利用する方が良いでしょう。
課金体系
海外のAPIでは実行回数によって従量課金されるものもあります。これらは利用するコードのミスによっては膨大な課金になる可能性があります。十分に注意した上で設計しなければなりません。課金アラートがあるサービスもありますが、開発者がミスに気付かないと丸一日課金され続けたといった事態になる場合も多々あります。
運用時の見積もりが取りづらい場合はデータ量やアクセス数などで試算してみる必要があります。一回あたりの処理は安くともAPI経由の場合は一気にアクセスが行われるため予想以上に高くなることもあります。
トランザクションが難しい
APIはアクセスごとに処理が行われます。そのため一般的なシステムでいうところのトランザクション処理が難しいのが問題視されます。トランザクションが必要なほど複雑な処理を実行しているのが問題なので、システム全体をシンプルに設計し直す必要があります。
また、どうしようもない場合はAPI提供元に相談してみるのも良いかもしれません。それによって新しいAPIを用意してもらえる可能性があります。ただしいずれの場合においてもトランザクションのサポートは難しいと考えておくべきで、ない前提でシステムを構築する必要があります。
システムダウン、メンテナンス時の対応
従来のアプリケーションサーバ、データベースサーバの組み合わせの場合、どちらかをメンテナンスする際にはもう片方は止めておくものでした。しかしAPI経由の場合はそういった意思疎通は困難と言えます。24時間365日、何の問題もなく提供され続けるシステムは存在しないと考えないといけません。
そのためエラーコードが返ってきたり、HTTPレスポンスがエラーになった時を考慮したコーディングになっているべきです。また、それに合わせたテストコードも書いておく必要があります。
ただし最近ではラップトップやスマートフォン、タブレットの普及によって一時的にオフラインの状態も少なくありません。そうしたオフライン時の動作と同じようにしておくのが良いのではないでしょうか。
セキュリティ！セキュリティ！セキュリティ！
データの取得はもちろん、更新や削除がある処理についてはセキュリティを十分に評価しなければなりません。不正な値を入れた時の処理、トークンが漏えいした場合の処理（サービスによってはトークンの更新ができないものもあります）、パスワードの取り扱いなど外部からでも確認できる項目があります。
クラウドサービスである以上、サーバ内部などはブラックボックスであることを許容しなければなりません。そのため、API提供元が信頼できる企業であるかどうかも大事な指針になります。
継続的にメンテナンス、機能追加されているか
企業が信頼できたとしても作られたAPIがそのまま放置されているのでは事業継続性が疑われます。お知らせがきちんと更新されているか、機能追加されているかといったチェックをしましょう。
更新されていないAPIはその内提供が終了してしまったり、問題があった時の対応も良くない可能性があります。
ドキュメントが整備されているか
ドキュメントはAPIを使う際の要です。ただ文書量があれば良いというわけではありません。分かりやすく、使いやすいドキュメントであるかいなかで、サービス提供元が利用者視点を持っているかどうかが分かります。
またドキュメントの整備も適切に行われていなければなりません。使えないAPIがそのままドキュメントに載っていたり、実際の動作と異なるといった場合は注意が必要です。
サポート体制
APIとドキュメントがあれば後は勝手にシステムが出来上がるわけではありません。実際に使っていく上で多くの問題、疑問が出るのが当たり前です。そんな時のサポート体制がどうなっているかは要確認です。
また技術サポート的な意味合いと、システムがエラーになった時のサポートは異なります。システムエラーについては24時間365日の体制が望まれるでしょう。技術サポートは概ね、平日の9〜5時といったパターンが多いように思います。
それ以外に利用者が集まったコミュニティ的なものがあると良いでしょう。エラーが出たときに、それが自分たちの使い方に問題があるか否か問題の切り分けに使えるはずです。また、利用者同士の方が目線が同じである分、解決が早いケースもあります。
APIを使ったアーキテクチャでは従来の構成と異なる問題が発生します。それらの特性を正しく認識することがシステムの疎結合であったり、開発の高速化につながります。
一見すると何でもできそうに見えるAPIですが、できないこともまた多いです。またベンダーの選定などもこれまでと異なる視点でみる必要があるでしょう。今回あげたような項目に注意して開発に取り組んでください。
