ディスカッション (11件)
HTTPの新仕様であるRFC 10008が公開されました。今回注目すべきは、これまでGETメソッドでは表現しきれなかった複雑なクエリや、リクエストボディを伴う検索リクエストを標準化する「HTTP QUERY」メソッドの登場です。これにより、キャッシュ可能な検索操作がよりセマンティックかつ効率的に実装可能になります。API設計に革新をもたらすこの新仕様を詳しく見ていきましょう。
待って、もう1万を超えてるの?
もしこれが本当にGETリクエストのクエリ文字列を置き換えるようなものになるなら、ブラウザのブックマークでリクエストパラメータを維持できるようにしてほしいな。
強力な動機付けとなる例を挙げれば、もっと納得しやすかったかもしれない。GETで簡単に表現できる例を出すのはかなり的を外しているよ。
巨大なJSONフィルタリング構造を持つQUERYや、画像入力のようなリクエストボディを想像してみても、リクエストボディをキャッシュキーの一部に含めるのは非常に奇妙に感じる。それは制限のない、ユーザー制御のキャッシュキーを意味することになるし、一般的かつ意味のあるキャッシュ戦略は実質的にリクエストボディのビット比較(あるいはハッシュ)くらいしかない。つまり、悪意のあるシナリオならキャッシュバスターは簡単にできてしまうわけだ。
これは非常にニッチなユースケースにおいて、明白な困難を伴うセマンティック上の奇妙な点を一度に複数引き起こしている。もし複雑なフィルタリングや画像のような複雑な入力を必要とするサービスを書いているなら、どんな形態のキャッシュ(例えばJOINの個別のデータカラムや、デコードされた画像の知覚ハッシュをキーにした埋め込みなど)であれ、それはHTTPレイヤーからはかけ離れたものであり、配線上の正確なビット表現とは確実に無関係になるはずだ。
そもそも、なぜこんなことを一般的な方法で捉えようとする必要があるんだ?
私なら、このキャッシュセマンティクスをPOST用の新しいヘッダーとして捉える方がずっといい。「Vary: request-body」のようなやつだ。これなら完全に下位互換性があるし、CDNのユースケースの0.1%を除けば無視しても問題ない。その0.1%のために動作が役に立つならそれでいいわけだし。
HTMLフォームがQUERYをサポートしてくれるのか気になるね。
<form action="..." method="query">
これがあれば、POSTフォーム送信で返されたページをリフレッシュした時に出るあの煩わしい再送信の警告を回避できる。QUERYはべき等であることが求められているからね。
IETFのワーキンググループでは、ボディを持つGETリクエストについて十分に検討されたが、結局は新しいQUERYメソッドを作成する方が良いという結論で却下された。明確に別のメソッドを作るという決定は、歴史的な相互運用性の問題と、HTTPのコアとなるアーキテクチャ定義への厳格な準拠という点に落ち着いたんだ。
もう何年もGETメソッドにリクエストボディを載せて送信してるけどね。
検索結果をクエリするためにHTTPクエリでQUERYメソッドを使えってことね。クエリパラメータを追加するなと。
名前が紛らわしいと思うな。『クエリ』という言葉はすでにHTTPリクエスト全般を指す言葉として使われているから。
RFCのタイトルを見ただけで混乱したよ。
まだあの前世紀に戻りたい人のために置いておくよ。
GET: Content (body) "定義されたセマンティクスはない"
GETメソッドにボディを含められるようにするのは悪くないアイデアだと思っていたけど、元の仕様によればGETのボディは完全に無視されることになっているらしいね。キャッシュの問題もあって、リクエストの肝となる部分が削ぎ落とされたボディの中に存在することになるから、それも破綻してしまうだろう。
余談だけど、ついにRFC番号が5桁に到達したんだな!
エージェントはこのRFCの範囲外なのは分かってるけど、これが簡単に拡張されてJSのEventSourceがAIのストリーミングクエリで使えるようになるかもしれないのは最高だね。
リクエストにボディが必要なせいでみんなPOSTを使っているし、結果のストリーミングにはtext/event-streamプロトコルがよく使われる。でも、これは技術的にはあまり適していない。状態は実際には何も変わっていないし、EventSourceは何だか頑固な理由でGETしか使えないからだ。だから多くのAPIは独自のパーサーで機能を再実装しているんだよ。