アプリケーション間で連携する手法
FileTransfer
ファイルを介して通信
Shared Database
データベースを介して通信
一昔前のトラベルはこれに近い？
Remote Procedure Invocation
ネットワーク上で同期的な関数呼び出しを介して連携
API多くはこれに該当
Messaging
お互いにメッセージをやりとりしながら進めていく
ScalaのActor Modelとか、Javasciprtのeventみたいな
RESTスタイルの特徴
ROAの「4つの概念」
リソース
名前とURIを持ったデータ（e.g. プランのデータ、施設のデータ）
URI
表現
リソースの形式（e.g. JSON形式、XML形式）
リンク
別のリソースを指し示すもの
ROAの「4つの特徴」
アドレス可能性
提供する情報がURIを通して表現できる
ステートレス性
ステータスを持たない
/A, /B, /Cの順にアクセスしないと情報が表示できないとかだと、ステートレス性がない
接続性
あるリソースが別のリソースとの関連を表すリンクを持ちうる
統一インターフェース
- リソースの取得(GET)
- リソースの作成(POST)
- リソースの更新(PUT)
- リソースの削除(DELETE)
リソースを取得する際に、/v1/getResourceのような形でURI中に操作を表す語彙が登場することがない
HTTPメソッドの利用がROAに沿っていれば、「安全性」、「べき等性」を持つ
安全性
サーバー側の状態が変更されることがない(≒いわゆる副作用がない)
GET、HEADがこの性質を持つ
べき等性
その操作を何度繰り返しても同じ状態となる
GET、HEAD、PUT、DELETEがこの性質を持つ
RPCスタイルの特徴
XML-RPC
RESTと対照的に複数のメソッドに対してエンドポイント(≒URI?)は一つ
JSON-RPC 2.0
HTTP(S)プロトコル以外でも利用できる
リクエストパラメータとレスポンスパラメータの対応付けを示すためにidを持つ
idがないリクエストはNotificationとみなされてレスポンスを返す必要がない→非同期リクエストに使える
複数の処理を一つのリクエストでまとめて送って、レスポンスもまとめて受け取ることが出来る。(Batch request)
RESTかRPCか
RESTの特徴
Pros
ROAという設計概念を適用し、制限を設けることで自明なコンセンサスを共有できる→実装者によってブレがでづらい
Cons
(RPCに比べると)自由度が低い(e.g. BatchRequestが出来ない)
RPCの特徴
Pros
NotificationやBatch Request等ユニークな機能が取り込める自由度の高さ
Cons
仕様に統一感が無くなり、理解しづらいものになる可能性が高い
RESTが向いてる
- 公開API等、不特定多数のクライアントがAPIを用いる
- 複数のエンジニアがAPIを設計する
- L7で分散したい
RPCが向いてる
- クライアントが社内に限定されている、SDKのような形でラップされている
- 限定されたエンジニアがAPIの設計をする
総評
APIってURLに対して、JSONを返せば良いんだよね、くらいに思ってたので、
結構色々なルールが定義されてることに驚きました。
今後APIを設計するときには、RFCとにらめっこしながら作る必要があるかなと思いました。