いまからweb apiやってく人のための地図

やっていくにあたって考えることを避けられない問題が紹介されてる。

どちらかというと砂利レベルの細かさだし、実装の話はほぼないので自分でやっていく段で適宜砂を詰めていく必要があると思う。すでにapi納品をやっていってる人におきましては得るものは少なそうだ。

「入門」詐欺みたいな本が多いけど、この本にこそ「入門」をつけとくべきじゃないか。

デファクトスタンダード

これはこうするのが正しい、これはこうしたらアカン、これは諸説あるけどデファクトスタンダードはこれ、これは色々あって議論がある、などと解説してくれるので親切。

とくに決めかねがちの問題は世論的にも決めかねがちってのがわかってよかった。好きにやっていく。

デファクトスタンダードでもなんでも、各事案で実在のでかいサービスではどのようにやっていってるか例を出してくれてるので、困った時とか納得いかない時にお好みの選択ができるようになってる。

先達に学べるの便利。

Railsつかってると自動的によしなにされてる部分が大きくて、そういうのを忘れてると即死しそうなので再認識できてよかった。

俺はただのユーザーとしての歴史しかないので、web apiといえば誰も彼もが使うことを想定したLerge Set of Unknown Developersでやるもんだと思っててその発想しかなかった。

そうしなければならない！と思ってやたらと親切なapi考えてたりしたんだけど、そうなるとあんじょうやらなければいけないことが多すぎて無理っぽさが出てくる。

しかし俺は別に広範な人々じゃなくて、スマホアプリとか他のwebサービス連系を目論んだやつを作らなくてはならないので、Small Set of Known Developersでやればええやんということがわかった。

考えてみれば当たりまえなんだけど、せまい視点のまちがった正しさで一人でツラくなりがちな俺みたいな技術者はもっと本を読むべきだと思った。

関係ないけどLerge Set of Unknown Developersの場合は「命じさせるな調べさせろ」になってSmall Set of Known Developers「命じさせろ調べさせるな」みたいになるのかなと思った。内部開発者むけweb apiてほぼ扱ったことないのでよくわかんね。

この章、最初から最後まで得るものが多くて大満足だった。

多分駆け出しマンはこの章読むだけでも価値がある。

配列json返すとセキュリティ的にあれなんでオブジェクトかえそうって話があって、へぇ、じゃあページネーション用のメタ情報そこにいれられていいね。

ってなったんだけど、レートリミットとかはヘッダに入れる一方でページネーションになるといきなりボディに入れるの整合性とれんなってなって結局配列は配列でかえしてメタ情報はヘッダに入れようという自己完結になった。