山盛りのAPIにどう対峙するか

2023/1/22作成

今時のウェブサービスであると、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を用意するのは方法かもしれないなぁとぼんやり思ったりもします。それが実現可能なのかどうか、細かく検討してなくて、ただ単に思いついただけの段階なんですけれども。

(2024/1/16追記)

最近、サイトコントローラというサービスがあることを知りまして。そんなもんも知らんかったんかこの情弱めとののしってくださいませ。まあ、そんな話はどうでもいいとして。

ホテルとか飲食店って今どきはネット予約が可能です。自前のサイトでネット予約も受け付けていますが、楽天トラベルとかそういった他サービスでも受け付けていますよね。ということは、楽天トラベルで受け付けた予約をどこかで自社の予約管理台帳ソフトに転記しないといけないわけですが、その役目を担っているのがサイトコントローラというわけです。予約サイトが単一だとそこで台帳管理も一括して行えばいいのですが、複数の予約サイトで予約を受け付けていますから、その予約情報をどこかに集約しないといけないのですね。そうしないとオーバーブッキングを生み出してしまいかねません。もしくはある予約サイトでは在庫がたくさんあるのに、他の予約サイトでは売り切れてしまって機会損失になってしまうかですね。

ということでサイトコントローラというサービスがあるのはいいのですが、これ実現するためにスクレイピングを行っているらしいんですよ。なんでかというと、各予約サイトがAPIを提供していないから。な、なんだってーって感じですが。

まあ予約サイトの気持ちもわからんでもないですよ。競合は使わず、自社のサービスだけを使ってもらいたいから囲い込みたいわけですよね。その商売上の心情はわからんでもないですが、その結果としてAPIを提供していれば不要になるスクレイピングの開発を他者に強要してしまっている。これ、社会全体としては非常に損失の大きい話なので、なんとかならんかなーと個人的には思うんですけど、なんとかならんのですかね。ならんかなー。

ということで、APIが山盛りあるのも問題だけど、そもそもAPI自体が存在しないって問題もあるんだなというところを追記した次第でありまする。

これ、別の言い方をするとAPIが提供されるのはそれが自社の商売の障害にならない場合に限るって話でもあるわけですよね。GitHubやQiitaがAPIを提供しているのはまさにそうでしょう。また、GitHubやQiitaにとってはAPIを提供することでサードパーティーによる開発が活発化して自社のサービスがより反映することも期待しているわけですね。

API提供が社会全体最適な方向なのは間違いないけれども、それが経済的なメリットに結びついていないとAPIが提供されないし、もしもAPI提供が経済的不利益を生むとしたら絶対に提供されないわけですね。ということで経営側に対してAPI提供を説得するには、それが社会全体はもちろん自社にとってもメリットがありますよということを示さないといけないわけですね。さて、そんな説得案があるかどうかですが。はてさて。