HTTP API の設計方向

Twitter の TL に Dropbox が API v2 で REST をやめたという内容がかかれている記事が流れてきた。

どれどれと思い、Dropbox API v2 のドキュメントを眺めてみることにした。

見てみると、たしかに Get 系の API だとしても POST を利用しているし、API の URL 設計に get_shared_link_file のようによく言われる REST っぽい設計は使っていなかった。

この方針は同意だ。自分は結構前に REST っぽい API を捨てることにした。だからといって REST API がダメだとかは思っていない。

一般ユーザが使う場合の API は REST API であるほうが慣れ親しんでいる場合が多いからだ。


AWS で利用されている HTTP API 仕様

AWS の DynamoDB の Erlang/OTP ドライバーを書いているときに気づいたのだが、AWS の一部のサービスはかなり独特な API の仕様になっている。

簡単に言うならば HTTP の PATH は全部 / で、メソッド はすべて POST という仕組み。判断は x-amz-target の中の文字列で判断する。

その文字列は DynamoDB_20120810.PutItem のように ServiceName_Version.Action という形式になっている。

この方法は完全に HTTP API を RPC として見ている仕組みで、自分にはすごくわかりやすいと感じた。あとは Body の JSON で全部がんばってくれよという方針も良い。

この仕様をパクって自前のオレオレフレームワークを作った

基本的にはミドルウェアに組み込む管理用の API 向けに作った。サービスに向けて使うつもりはない。


gRPC という最適解

ただ JSON Schema はやはりめんどくさいので、なにかいいのがないかなとずっと探しているのだが、結局 gRPC に落ち着きそうという気持ちになってきている。

JSON over HTTP は Protocol Buffers over HTTP/2 な gRPC に取って代わるのだろう。ストリームも可能だし、何より仕様がきっちりしているし、Google が内部でガッツリ使っているのは良い。

自社の製品が Golang なら良かったのだが、 Erlang だと gRPC をきっちり実装しているものはなく、まだ使えないでいるし、当面使わないだろう。

gRPC は今までの API に対する回答の一つなんだと考えている。自分は gRPC を見据えつつ、当面は JSON over HTTP + WebSocket で戦っていくのだろう。