RESTful API の設計のキホン

2016/10/12 社内勉強会で使ったスライドを社外向けに一部加筆訂正したもの

[ono_matope]

例えばgRPCだと .protoファイルが仕様そのものになるから、コンセンサス自体が必要なくて堅強という印象を持ってる

[marisatokinoko]

(正直なところ外部にリソース公開して自由にロジック組んでねっていう時でなければwebのrestful apiって無意味なのでは、と最近思う)

[parasporospa]

どういうわけかRESTと聞くと不快になる。現実的なメリットがほとんどない割に妙に原理主義的だからだろうか。開発者の間で混乱を招くため有害ですらあるな

[Kiske]

良い

[suthio]

言いたいこと大体書かれて嬉しい

[rgfx]

（まーRESTなんて、バックエンドをマイクロサービス構造で賄うんでなけりゃ意識することなさそうだもんなあ。

[slash_01]

良いまとめですね。

[gologo13]

いいまとめ。patch 更新は知らなかった。

[thetacpa]

“http://twitter.com/Cside_”

[kitokitoki]

limit-offset の pagenation

[biwakonbu]

後で読む

[n2s]

27枚目からREST以外の話も

[takatama]

同意。RESTの本質はリソースの設計

[tohokuaiki]

複数人で設計する時かー。まぁ、過去の自分は他人って言うし一人でもRESTfulに作ってれば後で役に立つのかも。

[tsukaby]

PATCHはRFC 6902にあるJSON Patchを使えというのは同意。PUTと似た感じでやるとフィールド削除を表現できなくて困ります（実際あった）。でも6902はProposed standardなので採用ちょっと悩む

[raimon49]

JSON PATCHってこんな感じで更新するんだ。

[UDONCHAN]

参考になる

[sysjojo]

コンセンサス取れ、って話になるんだろうけど、往々にして「悪い例」が顔を出す。 SOAPはsimpleではなくなってフェードアウトしてったけど、wsdlだけはいろいろ手間が省けた。一人で作るなら関係ないんだろうけど。

[yutaka_maruoka]

これとJavascript覚えればだいたいBluemixつかいこなせるんじゃね！？

[shikiarai]

いい加減導入してみたいのでやる

[iekusup]

ほー。

[tyru]

JSON Patch 知らなかった。LIMIT OFFSET も DB の挙動参考になる。

[chroju]

GETの結果がフラットな配列じゃなくて包まれてるのなんでだろと思ってたけど、そういうことか。

[field_combat]

limit offset気をつけよう

[efcl]

REST APIについて。 ページングのAPIの問題点

[habuakihiro]

これは良い資料。

[otchy210]

limit offset やっちゃいがち。確かに大手のちゃんとした API はみんな cursor 方式だな。

[kazuph1986]

limit-offsetのとこ

[ryota-murakami]

ちょうどAPIを作る必要があったからありがたい！

[ohbarye]

API, サクッと作れたとしても、複数のクライアント（web / native）で共有しだした途端に身動き取りづらくなるので最初の設計が本当に大事とここ1年で学んだ

[tune]

偏りがなく王道でよく整理された資料! ありがたい

[ko-ya-ma]

よくまとまっている