今時のウェブサービスであると、APIが用意されていることが増えました。GitHubにしてもですし、Qiitaにしてもですし。いちいちクローリングしたりSeleniumでコントロールしたりするのは不毛ですし、デザイン変更される度にXPathが壊れて対応が必要になるのはもっと不毛です。ということでAPIが用意されるのはいいのですが、次の段階として別の不毛な社会がやってきそうな気がするのでそのメモ書きです。
というのはですね。世の中に多数のAPIが登場して、それに都度対応していくのってそう簡単ではないですよねってことです。たとえばAPIを提供してるサービスが100個あるとして、APIを利用するアプリも100個あるとします。とすると、100個のアプリがそれぞれ100種類のAPI呼び出し処理を実装しなきゃならないわけですよね。合計1万回の実装が発生してしまう。これはなかなかディストピアではないですかね。
従来的なインターネットではこれはプロトコルを規定することで解決していたんですよ。メールならSMTPやPOPというプロトコルが決まっていて、プロトコルに従って実装されているならば、それぞれの組み合わせは問題にはならなかった。メールサーバが何であって、メールクライアントが何であったとしても問題なく動作した。もちろん組み合わせによってトラブルがなかったわけではありませんが、大抵は実装がプロトコルから外れていたことが原因だったので、そこを直せば大丈夫だった。
一方、今のウェブAPIってこうしたプロトコルの規定って誰もしていません。機能的にも複雑ですから、そう簡単には規定できないとも思えますが。とはいえ、今の調子でAPIが増えていったら、いつか臨界を突破して開発不能な時代がやってきてしまうかもしれない。今の時点でも、ITエンジニア不足って言われているけど、こうした爆発する組み合わせに愚直に対応してしまっているからこそ起こっているのかもしれないし。
ではどうしたらいいのかっていうと、いい解決方法も思いつかないんですけどね。最近BFF(Backend for Frontend)という概念を知りました。BFF自体はブラウザ上で動作するフロントエンド(JavaScript)用の技術なんですが、この考え方を拡張して、どこかにAPIの集約センター的なメタAPIを用意するのは方法かもしれないなぁとぼんやり思ったりもします。それが実現可能なのかどうか、細かく検討してなくて、ただ単に思いついただけの段階なんですけれども。