API のオーケストレーション層
Rebuild: 35: You Don't Need API Version 2 (Kenn Ejima) で話題になった API のオーケストレーション層(ラッパー層)を設けるという方法について、作っていたシステムでそういう事をしていた(因にこの作りにして 2 年目くらい)。
# ただし API のバージョニングという観点で作った訳ではない
システム感じはこんな感じ。
自分の担当は 上図の Backbone.js と Python まで。
ここまでをフロントエンドとしている。
バックエンドの API は他の人が作っていて、複数のシステムが動いている。
# 一部自分が作ってるのもあるけど
# バックエンドの URL はそれぞれ異なる(つまり物理的*1にサーバは別)
フロントエンドの Python サーバーはバックエンドを基本的には JSON-RPC*2 で呼んで結果を受け取って、クライアントに渡す。
またフロントエンドが RPC だけでバックエンドを呼ぶだけではなく、バックエンド側の情報をリアルタイムにクライアントに情報を表示したいたという要求があった。
バックエンド側に WebHook っぽいものを用意して フロントエンド API サーバの URL を登録し、バックエンド側で処理が終わったら POST で呼び出してクライアントに返すなどをやっている。
メリット
- クライアントがバックエンドのサーバと直接やりとりするのではなく、一層挟む事によって自由度が広がった
- クライアント側で処理する必要がないものはサーバ側に持ってくる事が出来た
- バックエンド側がも開発中の時はとりあえず Python でダミーのデータを返すようにした
- バックエンド側が対応完了になったらダミーをやめる
デメリット
- 複雑になった(複数人でやる場合は担当が決まるので責務がはっきりする)
- バックエンドに API が増えたら、クライアント側、ラッパー側両方に対応を入れないといけない
- 一層挟むので速度が気になる
- 現状クライアント(Backbone.js)がリクエストを発行して、データを取得するのにだいたい 200msec くらいだけど、利用者数が増えるとどうなるか分からない
システムがモノシリックな作りな場合はあんまりメリットが見えないと思うけど、SOA 的な作りをする際には良いと思う。
あ、因に本題の URL に API のバージョン情報を加えるかどうかは、バージョン番号を付与してる。
加えた理由が元々バックエンドが SOAP でしかやりとりできなかったのが、JSON-RPC で出来るようになった時に元のを壊したくなかったからやった。
やったのはいいけど、いつまで昔のバージョンのを残しておくかという元々の問題提起はまさに直面した。
結局今も残ったままだし、バックエンド側が完全に廃止しないと消せないかな。
ただしバックエンドと切り離してるからフロントエンド側で廃止するなどの判断は自分になるので、そういう意味では楽かな。
追記:
rebuild.fm 57:18くらいで「どういう API になるのかな?」とあったけど、内はまさにクエリインターフェイスみたいな感じになってる。
バックエンドで検索条件を受け付ける口があるので、そこに対して JSON-RPC でパラメータとしてクエリを定義して送信する形。
