HTTP API の設計方向

V
V
Oct 1, 2016 · 4 min read

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 で戦っていくのだろう。

Welcome to a place where words matter. On Medium, smart voices and original ideas take center stage - with no ads in sight. Watch
Follow all the topics you care about, and we’ll deliver the best stories for you to your homepage and inbox. Explore
Get unlimited access to the best stories on Medium — and support writers while you’re at it. Just $5/month. Upgrade

Get the Medium app

A button that says 'Download on the App Store', and if clicked it will lead you to the iOS App store
A button that says 'Get it on, Google Play', and if clicked it will lead you to the Google Play store