企業間におけるAPI利用が拡大していくと、API自体が利益を生み出すAPIエコノミーが広がっていきます。APIエコノミー自体については以前記事にしていますが、その中で考えるべき視点がサービスのAPI化です。
より複雑な処理をRESTfulで処理する
単純なデータベース構造やモデルの公開はRESTfulによって処理を行えます。RESTfulは開発者にとって分かりやすく、使い勝手の良いAPIフォーマットになりますが、幾つかの問題点があります。その一つがクライアント側（利用側）のコード量が増大することです。
単純なモデル操作だけをRESTfulで公開している場合、複数のモデルを連携させるような操作を実現するにはAPIを利用する側のコード量が増えがちです。例えばカレンダーに顧客との打ち合わせを追加する場合、RESTfulで考えると次のようになります。
- 顧客APIに対して顧客の存在確認を行う（GET）
- データがなければ作成を行う（POST）
- カレンダーAPIを使って日付が空いているか確認する（GET）
- 空いていれば顧客と自分の情報を合わせてスケジュールを登録する（POST）
このロジックはすべてクライアント側で行わなければなりません。さらに4のスケジュール登録自体は顧客データを取得していなくても実行できてしまうため、作り手によってデータ構造が変わってきてしまう可能性があります。
サービスのAPI化を考える際には、これらの処理をある程度パックにし、一つのAPIとして公開するのが良いでしょう。必ず踏まなければならないステップがあるならば、それはクライアントではなくサーバ側で処理する方が効率的です。
RESTfulではネットワーク通信量が増える
先ほどの例においても4回のネットワーク通信が発生します。ネットワーク通信はどこでエラーが発生するか分からないため、なるべく少ない回数で終わらせる方が効果的です。システム連携が前提のAPIではコネクション数増大によるリソース欠乏にもなりやすく、その意味でもコネクション数は少ないに越したことはありません。
ネットワーク数を減らす方法として、バッチ処理で複数の処理を一回で送れるようにするものもあります。しかしこの場合、顧客の存在確認を行った上でデータの作成を判断すると言った条件処理は困難です。結局、必要なデータを集めて判定を行ってAPIをコールするというステップは変わりません。
通信を減らすための方法として、検索してデータがなければ作成して返すといったようなAPIを用意する方法が考えられます。よくある処理について一つにまとめてしまうことでクライアント側、サーバ側の処理両方を減らすことができるでしょう。
また、内部のメソッドを呼び出すのもお勧めです。この時、HTTPを経由して呼び出すのはよくありません。コネクション数が増えてしまうからです。ただしマイクロサービスによってシステムを疎結合にしている場合はうまくいかない可能性があります。
RESTfulはトランザクションに弱い
RESTfulの弱点としてトランザクションがあります。業務システムにおいて途中でエラーが起こった時のロールバック処理は必ず求められるのですが、RESTfulではうまく実装するのが困難でしょう。これはHTTPの仕組み上、一回一回のコネクションで閉じてしまうと言う問題にも関係しています。
一度にデータをすべて受け取れれば、サーバ内部ではトランザクションを使った処理が可能になります。特に企業間におけるAPI活用においてはトランザクションを意識した設計が必要になるでしょう。
RESTfulというとデータベースのテーブルはモデル単位での操作が思い浮かびますが、モデルの操作だけで済むケースは多くありません。開発者がそのAPIを使って何を実装するのかを意識し、彼らにとって使いやすい形で公開する必要があります。
データベースではなく、利用する機能やサービスと言った単位でRESTfulなAPIを作ると使いやすいでしょう。
