大企業であったり、複数の事業をもった企業では部署やサービス毎にAPIを公開することがあります。統一されていない、基準のない中でAPIを公開すると、ユーザにとって不利益をもたらすことになったり、企業にとっても管理、運用コストの増大というデメリットにつながります。
今回はそんな管理されていないAPI公開に伴う問題を紹介します。
セキュリティリスク
APIの認証技術は幾つか存在します。例えばOAuth2/OAuth1/トークン/Basic認証などです。これらがサービス毎にばらばらの基準で提供されているとどうなるでしょうか。あるサービスはOAuth2で認証し、別なサービスではトークンを発行したりします。
どの認証技術を用いるかはサービスや機能レベルによって判断されるべきで、担当者の考えだけで決まるものではありません。とても簡単なデータしか提供しないのにセキュリティ基準が非常に厳しかったり、重要なデータをトークンだけで公開したりするのは問題があります。企業全体としてのセキュリティ基準に沿って進められるべきです。
操作性の違い
長い歴史の中でAPIのトレンドが変化してしまい、古いAPIと新しいAPIでインタフェースが異なるというのはよくあります。しかし最近リリースしたものであるにも関わらずインタフェースが不統一なのは開発者にとってストレスです。インタフェースが異なればライブラリも変わってくるでしょう。同じ企業が提供するサービスであるにも関わらず、それぞれのAPIを習得するコストが大きくなります。
小さなところではURLがキャメルケースなのかスネークケースなのかであったり、削除がHTTPメソッドなのかパラメータなのか、パスの切り方がRESTfulの原則に従っているか否かと言った違いがあります。いずれも小さな違いではありますが、利用者視点で見ると、そこで躓くと大きなストレスになります。
機能差
サービス毎にAPIを作っている場合、その開発にかけられるコストは自ずと変わってきます。その結果、あるサービスではOAuth2で認証してクォート管理されていて、別なサービスではトークンだけで全く管理されていないといった事態になります。多くの開発者は最初に触ったAPIを基準に考えてしまいますので、サービス毎に基準が異なるのは問題です。
APIとしての基本機能については統一された基準で実装されている方が良いでしょう。そうすることで共通ライブラリが作成できる可能性が生まれ、一つのライブラリですべての機能が同じように開発できるようになります。
更新コスト
APIは一度公開したら終わりではありません。開発コストに差が出るということは、更新についても同じことが言えます。全く更新されないAPIは完成度が高いという意味ではありません。放置されたAPIからは開発者も離れてしまうでしょう。
アプリやWebサービス側とAPIの機能差が発生するのもよくありません。一度APIを公開した後は、できる限り機能を追従して実装されるべきです。それができているAPIとできていないAPIが存在するのは開発者の心象としてよくありません。
ライブラリ開発コスト
APIはそのままでは使ってもらえないかも知れません。そこでAPIの利用をラップできるライブラリの開発がよく行われます。プログラミング言語は限られますが、ライブラリがあることで利用してくれる開発者は増えるでしょう。ですがサービス毎に異なるURL基準になっていると、それだけで開発コストが上がってしまいます。
サービスごとに分岐が発生したり、認証方式を変えたりするのはとても面倒です。その結果としてサービス毎にライブラリが存在してしまい、開発者は複数のサービスを組み合わせたいと思った時にライブラリを複数インストールしなければならなくなります。
APIは企業やドメインごとに統一して提供されるべきです。一般的に開発者の期待する形に合わせておくことで利用を促進できます。提供側にとっても統一されていることで理解がしやすく、どのサービスに関係するAPIなのかもすぐに分かるようになります。
APIの統一のためにはAPIゲートウェイが最適な解決策になるでしょう。APIゲートウェイを使うことで一旦アクセスをすべてAPIゲートウェイで受け取って各サービスに分かれてアクセスするようになります。開発者の視点としてはエンドポイントが一つになるので統一感が出ます。また、APIのパスを作るルールも統一して管理されるので、イレギュラーをなくして管理できるようになります。
