GETのURL長すぎ問題とPOSTのキャッシュ効かない問題をスマートに解決するQUERYメソッド、早く広く普及してほしいな
今後もますます複雑になるであろうHTTP。
なるほど。リクエストの上限に引っかかり始めたので、良さそう。 ただし、コピペで同じ画面が参照できるにはならないので、検索キーを発行してリダイレクトするのか、何かしらの手当が必要そう。
bodyを付けるために全部postでやってたら、別の部署の人からapiの目的によって使い分けろとツッコミ受けたなあ。聞き流したけど
よし 全部QUERYでいいな
GETでパラメータ何個も渡すのやめようってことね。良いのでは
GETでもボディを付けられるが仕様上禁止なのでプロキシやキャッシュに握りつぶされる可能性がある、というが、それなら新メソッドQUERYも新し過ぎてプロキシやキャッシュに握りつぶされそう。
RESTの夢はgRPC/GraphQLに壊されQUERYで復活する（のだろうか）。http methodて種類少なくて拡張余地大きいよね
条件がネストした構造になると表現しづらいは理解しつつ、検索条件がURLに丸見えになるからこそブックマーク保存したり他人に共有できるので、QUERYが主流になったら別途検索条件を伝える必要があるなど不便になりそう
これがそうだとは言わないけど、イケてない要求を通すために仕様の方を拡張するのは地獄の始まり感があるんだよなぁ…。要求の仕方の方に頭使うことを放棄してる感とか。
一般的なブラウザではbodyの内容を??とか#?とかで区切ってURL扱いしたりするのかも……？
勘違いされがちだけどformがQUERYに対応するわけではない……（ブックマークの件）
今までbody使いたいからというだけの理由で本来GETなリクエストをPOSTで実行していた部分がQUERYに置き換えられるというだけのように思える
"「GETのボディには意味を持たせてはいけない」とされており" そうだったのか
POSTメソッドを使ってリソース取得を行うような奴をちゃんとしようぜ！みたいな話なのか？
新しいHTTPメソッド「QUERY」をHono + Bunで実装してみる - Qiita
GETのURL長すぎ問題とPOSTのキャッシュ効かない問題をスマートに解決するQUERYメソッド、早く広く普及してほしいな
今後もますます複雑になるであろうHTTP。
なるほど。リクエストの上限に引っかかり始めたので、良さそう。 ただし、コピペで同じ画面が参照できるにはならないので、検索キーを発行してリダイレクトするのか、何かしらの手当が必要そう。
bodyを付けるために全部postでやってたら、別の部署の人からapiの目的によって使い分けろとツッコミ受けたなあ。聞き流したけど
よし 全部QUERYでいいな
GETでパラメータ何個も渡すのやめようってことね。良いのでは
GETでもボディを付けられるが仕様上禁止なのでプロキシやキャッシュに握りつぶされる可能性がある、というが、それなら新メソッドQUERYも新し過ぎてプロキシやキャッシュに握りつぶされそう。
RESTの夢はgRPC/GraphQLに壊されQUERYで復活する（のだろうか）。http methodて種類少なくて拡張余地大きいよね
条件がネストした構造になると表現しづらいは理解しつつ、検索条件がURLに丸見えになるからこそブックマーク保存したり他人に共有できるので、QUERYが主流になったら別途検索条件を伝える必要があるなど不便になりそう
これがそうだとは言わないけど、イケてない要求を通すために仕様の方を拡張するのは地獄の始まり感があるんだよなぁ…。要求の仕方の方に頭使うことを放棄してる感とか。
一般的なブラウザではbodyの内容を??とか#?とかで区切ってURL扱いしたりするのかも……？
勘違いされがちだけどformがQUERYに対応するわけではない……（ブックマークの件）
今までbody使いたいからというだけの理由で本来GETなリクエストをPOSTで実行していた部分がQUERYに置き換えられるというだけのように思える
"「GETのボディには意味を持たせてはいけない」とされており" そうだったのか
POSTメソッドを使ってリソース取得を行うような奴をちゃんとしようぜ！みたいな話なのか？