HTTP API の設計方向

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

[yayugu]

REST使わなくていいよね。ただgRPCみたくactionの指定にpath使うのまで使うのをやめてしまうとnginxなどのreverse proxy のログか調べにくくなったりnewrelicがいいかんじに機能してくれなかったりとデメリットも多い

[nekoruri]

結局APIでやりたい事はリソースの交換では無くRPCだったってことなんだよなあ。CQRS/GraphQLなんかの流れもそうだし。

[n314]

RESTって非正規化禁止のDBみたいな感じがする。

[rekp]

RESTな設計にし辛い事が世の中に多すぎるよ。

[TokyoIncidents]

徐々に転換していくのだろうか。ブコメにもあったけど適材適所だとは思う

[kiririmode]

POSTで全部やる的な

[snowlong]

“SON Schema はやはりめんどくさいので、なにかいいのがないかなとずっと探しているのだが、結局 gRPC に落ち着きそうという気持ちになってきている。JSON over HTTP は Protocol Buffers over HTTP/2 な gRPC に取って代わるのだろう。”

[sugimomoto]

APIでやりたいことがRPC的なことかどうかは、コンテキストで変わる。GetSharedLinkなんてRPC的な考え方で明確だけど、FileとかUser一覧を取得したいとかだとコンテキストはユーザー側で変わる。それはREST的アプローチが向いて

[bigbuddha]

新しい時代に入りつつあるんかな

[NetPenguin]

良い。

[lastresortan]

2周回って元通り。

[itotto]

わかる

[kwhrtsk]

gRPCの良い点は双方向通信をサポートしている点とIDLが簡潔な点。この二つはOAS(Swagger)に無い長所なので、fetch APIがHTTP2をサポートするなりしてgRPC-Webがブラウザネイティブになれば一気に普及する気がしている。

[taruhachi]

間違ってなかった。

[cl-gaku]

だったらJSON-RPCでいいや

[snjx]

REST以外のAPI設計の考え方。

[tkawa]

適材適所だけど、どちらにしても独自仕様ではなくできるだけ標準仕様を使うのがよいと思います

[ilyaletre]

CQRSでいうCommandがRPCでQueryがRESTfulになっていると考えば、自然に使い分けられないかな。CommandとQueryでエンドポイントが分かれそうだけど。

[bamch0h]

今趣味で作ってるやつはサーバーサイドgolang だからgRPC使ってもいいのかな。クライアントサイドはjsなんだけどgRPCで通信できるん？

[ledsun]

最近、（ブラウザからは）フォームのhidden fieldでjson投げるのが、クライアンドの実装が素朴で良いなと思っています。（メソッドを使い分けれないので、urlは複雑に。複雑なサービスには、向かないと思います）

[mallowlabs]

API は GET をやめていくのが流れ。時代は gRPC。

[ko-ya-ma]

gRPCか

[raimon49]

JSON over HTTPからProtocol Buffers over HTTP/2へ。ペイロードがJSONでも全部POSTで包む設計は豪気で良いなとは思う。サーバのリクエストログから集計や監視みたいなところが懸念だろうか。

[kijtra]

URL設計とか考えてると無駄な時間使ってる気がする時あるね。

[key_amb]

REST から RPC へ

[progrhyme]

REST から RPC へ

[gologo13]

適材適所だと思うけどね。複雑なビジネスロジック提供するAPIはRestで表現できない。

[howdy39]

RESTじゃ設計しにくい部分あるもんなぁ。悩ましい。

[yamadar]

眠気が覚めたら読み返す

[learn]

Dropbox が API v2 で REST をやめた

[nakag0711]

Sun RPC over HTTPSの時代到来か