パルカワ2

最近はFlutterをやっています

Androidアプリ・iPhoneアプリのためのAPIの互換性、バージョニング

ちょっと考えた。

やり方はいつ考え、決めるべきか

APIのバージョニングや互換性とかめんどくさくて、あまり関わりたくない。関わりたくないので後回しにしがち。しかし、残念なことに必ず出てくる話なので、前書いたプロジェクトの準備の段階で考えておく必要があると思っている。

やり方1: 古いクライアントは切り捨て、アップデート必須

サーバ側で対応しているクライアントのバージョンを保持していて、リクエストしてきたクライアントがそのバージョンより低かったら「バージョンアップしてください」とかそういう文言を出す。
これ、外部に公開しているAPIとかだと出来るわけがないのだけど、公開していないAPIなので、それでも良いと思う。
メリットは、切り捨てていくので、メンテするものが増え続けないこと。
デメリットは、アプリのアップデートが必須になること。サーバ側で対応しているクライアントのバージョンを上げ忘れると破滅すること。

やり方2: 古いクライアントは切り捨てず、頑張る

このクライアントのバージョンはこのURLを使って、あのクライアントのバージョンはあのURLにリクエストを送る、みたいなの。
メリットは、ユーザーがアプリをアップデートしなくてもいいこと。
デメリットは、メンテするものが増え続けてしまうこと。どのバージョンがどのURLを使っているのかわかりにくいこと。

やり方1 と やり方2

やり方2をやっていれば、やり方1は不要という感じがするけど、例えば「バージョンAでは反映されるべきデータをサーバに送ってきてない!」とか金玉がヒュンってなるような致命的なバグが出た時、そのバージョンAからは必ずアップデートさせたいとかあるので絶対実装する必要がある。

やり方1・やり方2でもないやり方3: Gates

http://amberonrails.com/move-fast-dont-break-your-api/が面白かった。HIDE YOUR BACKWARDS COMPATIBILITYあたり。
ただこれは、公開されているAPIの話なので、自分たちしか使わないAPIの話とは微妙に違うとは思う。クライアントのバージョンに紐付いて、そういうフラグみたいなのを持っていると同じようなことが出来て面白いのかもしれない。実装もRailsのbefore_actionとかでわりかし楽に出来そうという気はした。

まとめ

Gates良さそうとか言いつつも、やり方1はどうせ必須なので、もうやり方1でいいんじゃねと思いました。みんなどうしてるのだろうか。