(2019-02-05更新)
業務用アプリケーションを作るとき、データベースを分散化したりWebアプリをメインにしながらも他の(Excelなどの)ツールから情報にアクセスすることを考えるならば、データアクセスにWeb APIを使うのが良さそうに思う。
目次:
ベストプラクティス
Web APIの設計について調べていて次の記事を発見。
ここの 関連データを埋め込む手段を作ろう という節には関連データーをレスポンスに含めた方がよいことと、必要なデーターをリクエスト・パラメータに含めようということが載っている。
N+1問題
上記ページにN+1問題というのが載っていた。 検索した複数件(N件)のデーターに対して1件ずつ関連情報を引き出そうとすると、最初の1回+N回のデータアクセスが発生するという問題。 以前から関連情報を調べようと思っていたけれどどんな名前で検索すればよいのかわからなかったが「N+1問題」という名前がついていることがわかった。
ここにN+1問題のRailsでの解決方法(includesを使う)が書いてあった。 CakePHPの場合はcontainを使うらしい。
contain を用いた関連データのイーガーロード - データの取り出しと結果セット - 3.7
「WebAPI 設計のベストプラクティス」に対するツッコミ
翻訳: WebAPI 設計のベストプラクティス - Qiita に対して賛成項目と反対項目、それぞれの理由が説明してある記事を発見。
検索は /search というエンドポイントではなく /books?author=john&title=my_book のようなリクエスト・パラメータでやるべきと書いてあり、その理由は「エンドポイントとして定義されている事象の部分集合として取り出すべきだから」とのこと。
また、関連情報を埋め込むときはHAL(Hypertext Application Language)に従って _embedded 属性の中に入れるべきとのこと。
関連情報の入れ方
_embedded 属性に関連情報を入れるやり方について次の記事を発見。
情報の格納にPUT、POST、PATCHのどれを使うべきか？
次のページを発見。
POSTは情報の新規作成。 PUTは情報の新規作成または更新。 PATCHは情報の一部分を書き換えるもの。
上記ページでは次のように書かれている。
たとえばもし Invoice というモデルがあって、その請求が支払われたかを示す paid というフィールドがあったとしたら、支払いが完了したらその paid フィールドを更新しますよね。
このとき、 /invoices/:id に対する PUT メソッドで paid フィールドを例えば true とかに更新するというのは HTTP セマンティクスとしては正しくない、と。
もし PUT を使いたければ URL のリソース表現は /invoices/:id/paid になるべきだよ、と。
Web APIをRESTfulに作ったとき /invoices/:id に対するPUTではそのInvoiceのすべての情報を送らなければならない。
しかしPUTではなくPATCHを使えば、たとえば paid: true のような更新したい部分の情報のみを送ればOK、ということなのかも。
