APIはシステム連携で使われるため、一度開発してから頻繁に手を入れなくなるかも知れません。しかし常に新しい人たちが使っていくことを考えると、レガシー化して古い技術を使い続けるのも躊躇されます。そこで今回はAPIがレガシー化しないための方法を紹介します。
常に手を加え続ける
APIは一度作って終わりではありません。むしろ放置してしまうと実装がどうなっていたのかを忘れがちで、半年や一年後にメンテナンスもできなくなります。その結果、メソッドを分けたりして、全体のバランスが悪くなります。
逆説的ですが、常にメンテナンスし続けることが結果としてAPIの寿命を延ばします。
フレームワークを積極的に使う
APIは進化の速い技術です。特にスマートフォンが出てからOAuth2のような技術であったり、GraphQLなども登場しています。すべてを実装していてはあっという間に廃れたAPIになってしまうことでしょう。
もし自社でAPIを開発、提供するのであれば積極的に外部ライブラリを使っていくべきでしょう。そうすることで実装を薄くことが実現し、メンテナンスも容易になります。もちろん、その際には長期的に使えて自社要件にあったフレームワークの選定が必要になります。
APIゲートウェイの活用
APIはただJSONの入出力インタフェースを追加すれば良いわけではありません。負荷対策であったり、クォート制限、認証なども必要です。そうした部分まですべて自社開発しているといつまでもリリースできないかも知れません。
APIゲートウェイはそうしたAPIの根幹になる部分を提供してくれるサービスになります。また、システム自体はJSONインタフェースを備えていなかったとしてもデータを変換してくれる機能もあります。APIゲートウェイの活用がAPI戦略において大事なポイントになるでしょう。
ワークフローに合わせすぎない
APIの設計に関わりますが、必要なワークフローをサーバ（API）とクライアントのどちらで持つかは大きな問題です。サーバ側の実装を厚くすると、クライアント側の実装は減らせます。ただしワークフローは変わりやすいことが多いため、影響を受けやすくなります。その結果、使わなくなるAPIも増えてしまうでしょう。そして新しいワークフローができるたびにAPIが増えていきます。
逆にワークフローに関係なく理想的なAPI設計を追求すると、クライアント側のコード量が増えていきます。スマートフォン、Webアプリケーション、IoTなどすべてにおいて同じような実装が増えていくのはムダな開発コストにもつながります。
難しい問題ではありますが、APIの独立性は寿命に大きく関わってきます。どちらかと言えば後者の方が長生きに、レガシー化しない傾向があります。
リリース直後は先進的であったり、標準的であったとしても時代の流れとともに新しい技術が生み出されていきます。そうした波に乗り遅れるとあっという間においていかれてしまうでしょう。特に標準技術が変わったにも関わらず古い標準のままであった場合、利用する側としては躊躇してしまいます。
APIは変化の激しい技術です。そうした波を乗りこなし、新しい技術も積極的に取り入れてください。
