2018-04-01

読んだ本

『現場で役立つシステム設計の原則』

ドメインオブジェクトについてや、DBスキーマの説明は数少ない書くべきドキュメントであるといった点はまあなるほどという感じだったが、Web APIの章はうなずけない部分もあった。具体的には、更新するときにPOST /books/1/updatesとしたほうが抽象度が上がり、リクエストする側が考えることが減るといった主張や、GET /members/1/nameGET /members/1/genderといった細かいエンドポイントにすべきといった主張のところ。前者はむしろPATCH /books/1/updatesとしたほうがクライアントから見たときにやりたいことが表現されており、実際どのようにサーバがデータを操作するかが隠蔽されていると思った。サーバの識別体系を知るのが密結合につながるとあるが、必ずしも実装と同じ構造にしなくてもよいいのだから、驚きが少ないインタフェースにしたほうがよさそう。後者は、URLでわけるのではなくパラメータfieldsにするとか、もはやGraphQL使うとか。こういう意見の相違が出るので、昨今はRESTつらいと言われているのかもしれない。

subscription

graphql-rubyのsubscriptionについて、Action Cableの動きの調査を経て、中のコードを読むことでどう動いているかやっと理解できてきた。

コメントを残す

メールアドレスが公開されることはありません。 * が付いている欄は必須項目です