Web APIの開発を担当しているswdyhです。
以前からWebサービスのサーバサイドの開発をしていたんですが、トレタに入るまでアプリのためのWeb APIの開発というのはしていませんでした。トレタに入って2年半くらいずっとアプリのためのAPIを開発していて、同じサーバサイドの開発でも、それまでとの開発とは違う点があり、悩ましくも面白く感じたのでまとめてみました。
サービスとアプリの話
トレタで提供しているサービスは、飲食店むけの予約管理サービスで、電話などで予約を受け付けたときに、iPadのアプリを操作して予約を入力してもらい、実際にお客さんが来店したときにはiPadを見て案内するというふうに使ってもらうものです。他にもいろんな機能やこだわりポイントがあるサービスなんですが、そのへんはWebサイトを見てみてください。
トレタのアプリはiPadのネイティブアプリで、ほぼ全てのデータをサーバ上のDBに入れていて、WebAPIを通して利用しています。WebAPIが動いていなければ、なにもできなくなりますが、複数のデバイスで利用でき、ローカルデータを同期しようとして、おかしくなるということもないという造りにしています。
Web APIと古いバージョンのアプリ
Web API開発にとって、相手がアプリであることの特徴は、古いバージョンのクライアントが残り続けるということにつきます。古いバージョンが残るということは、古いバージョンを使い続けられるようにするには、古いバージョンが想定しているAPIを維持しておく必要があるということです。
これはアプリではなくても、公開用のWebAPIを作る場合に似ていますが、公開用の場合は機能を絞ったり、安定して長く使ってもらうように準備して作る点がちょっと違います。トレタのようなサービスをつくるにあたっては開発スピードが重要で、WebAPIもどんどん開発する必要があり、それをしながら互換性を維持するのはより大変です。
互換性の話
実例ではないんですが、互換性についてかんたんな例をあげてみます。電話番号のデータを文字列で用意していたとします。
{ "phone": "090-1111-2222" }
ところが開発が進んでやっぱり複数必要だよね、っていう話になったとします。
{ "phones": ["090-1111-2222", "090-1111-2223"] }
単純にこう変えてしまうと、最初のWebAPIを使う前提でつくられたアプリがリリース済の場合、そのアプリが使えなくなってしまいます。あたり前すぎますが、これはアプリ向けのWebAPI開発にとって一番重要なことだと思っています。この例は単純なですが、日々これの積み重ねで進んでいくので、常に気を配る必要があります。
この問題の対処方法としては
- 別のAPIとして提供し、古い方をdeprecate扱いにする
- 両方の値をいれてphoneの方をdeprecate扱いにする
deprecate扱いにするというのは、アプリを作るひとむけに次のバージョンからは使わないように作ってもらうということになります。APIドキュメントを整備したり、アプリをつくるひととのコミュニケーションが大事かなと思います。
古いバージョンを開いた場合、アプリを開いたときに「アップデートをしてから使ってください」というメッセージをだして、使えなくしてしまう。という手もありますが、なかなかそういうわけにはいかない場合が多いと思いますし、トレタでもユーザの不便さを考えてしていません。
Web/WebViewアプリ/ネイティブアプリ
もうひとつWebViewやWeb技術でUIをつってもこの問題を解決できます。トレタのアプリでも一部WebViewを使うところはありますし、過去WebViewだった部分もあります。
ここの議論だけでも大きな話なので、トレタでどうしているかだけ紹介します。飲食店の現場のオペレーションで使う場合には、電話を受けながらでも素早い入力できるUIやデバイスのマイクをつかった録音機能などのネイティブの機能をフルに活かしたアプリを提供し、モバイル用途やオーナー/チェーン店本部むけの機能についてはWebでつくるという使い分けをしています。
計測とAPIの停止
ちょっと話を戻すと、互換性を維持するのが大事という話しをしました。今のところトレタのWebAPIは互換性を維持し続けていて、最初のアプリをリリースしたのは2年以上前ですが、そのときのアプリを起動してもきちんと動作するようになっています。更に言うと、最初のバージョンだけでなく、最初のリリースから今までの間に約40回のリリースをしていて、40バージョンのアプリがそれぞれ動作するようにWebAPIを保守しています。
とはいえ、互換性を維持し続けるコストもかかるので、どこまで互換性を維持しつづけるのかを考えておく必要があると思っています。そのためには、どのバージョンのアプリがどれくらい使われているかを知るというのが大事です。
トレタではすべてのWebAPIのアクセスのログをGoogle BigQueryに保存していて、いつでも簡単に検索したり集計できるようになっています。アプリのバージョンやiOSのバージョンの割合を調べたり、どの店舗さんが古いバージョンを使っているのかというのも調べたりしています。
今のところトレタのWebAPIは実際に停止するところまではやっていないんですが、ログの集計からdeprecateなAPIを使うバージョンのアプリからのアクセスが一定期間ないことや、deprecateにしてからの期間を基準にして、実際に停止するということをやっていこうかと考えています。
B2Bならでは
またトレタでは実際に営業担当が飲食店さんとのつながりをもっているので、古いバージョンやバグのあるバージョンを使っている場合に、担当者を通じてアップデートをお願するということもしています。地道な方法ですがそうやって古いアプリをなくしていくとともに、新しいバージョンの機能を知ってもらうようにしています。これはコンシューマ向けのサービスではあまりないことかなと思うのと、営業と開発の距離が近く、協力して問題を解決していけるといのもトレタでの開発の面白さの一つだと思っています。
まとめ
互換性を中心にトレタでのWeb API開発で得た知見をまとめてみました。互換性以外にも考えるべきことはたくさんあって、トレタでは外部連携先がかなりの勢いで増えつつあり、外部連携用のAPIをどう設計して運用するかが今もっとも悩ましくて面白いと思っています。いまの試行錯誤からよさそうなパターンや知見をみつけて、まとめられればいいなと思っています。
Web APIの開発(おもにRails)、Web APIをささえるインフラ(devOps)、iOSアプリの開発(Swift移行中)など、トレタではエンジニアを募集しています。
