メインコンテンツへスキップ

Go Proposal Weekly Digest

Go言語のproposal更新を毎週お届け

#80058likely_accept

net/http: add MethodQuery constant

ステータス変更: active likely_accept

要約

AIによる要約であり、誤りを含む場合があります。

概要

HTTP QUERYメソッド（RFC 10008で定義された、GETとPOSTの間を埋める安全かつべき等なメソッド）に対応するhttp.MethodQuery定数を、net/httpパッケージに追加する提案です。

ステータス変更

active → likely_accept
2026年7月29日と8月20日の提案レビュー会議での議論を経て、「likely accept」と判定されました。会議では「これらの定数にはコンパイル時チェックというわずかながら実利的な価値がある」という点、および「何を追加基準とするかについて合理的なルールを定められれば、新規追加は許容できる」という点が確認されました。すでにMethodGet〜MethodPatchまで一通りのRFC由来メソッドが定数化されている中、QUERYだけを除外すると「標準化直後に真っ先に使われるはずのメソッドだけが欠けている」という不自然な特別扱いになる、という指摘が決め手になったとみられます。

技術的背景

現状の問題点

net/httpにはMethodGet、MethodPost、MethodPatchなど主要なRFC標準メソッドの定数がすでに用意されていますが、RFC 10008（2026年に標準化）で定義された新しいQUERYメソッドに対応する定数は存在しません。開発者はQUERYメソッドを使う際、生の文字列"QUERY"を直接記述する必要があり、タイプミス（例: "QUERy"）によるバグの温床になりえます。HTTPメソッド名は大文字小文字を区別するため、サーバー側の実装によってはQUERyとQUERYを別物として扱う可能性があり、これは特に見落とされやすい問題です。

提案された解決策

net/http/method.goに以下の定数を追加します。

const MethodQuery = "QUERY"

これはMethodPatch（RFC 5789で追加）と同じパターンを踏襲するものです。なお、Content-Lengthの扱いやリダイレクト時の挙動といったセマンティクスの詳細は、必要であれば別途議論するとされています。

これによって何ができるようになるか

QUERYメソッドは、複雑な検索条件やバイナリデータなど、GETでは表現しづらい大きなリクエストボディを安全かつべき等に送信したい場面で有用です。grpc-gatewayのようなAPIゲートウェイやOpenAPI 3.2（QUERYを正式サポート）を利用したAPI開発、複雑な検索・フィルタリングAPI、GraphQL的なクエリをRESTfulに扱いたいケースなどで活用が見込まれます。定数化により、コード生成ツールやAPIクライアント実装が生の文字列に依存せず、コンパイル時に型安全にメソッド名を参照できるようになります。

コード例

// Before: 生の文字列リテラルを使用（タイプミスのリスクあり）
req, err := http.NewRequest("QUERY", url, body)
// After: 新しい定数を使った書き方
req, err := http.NewRequest(http.MethodQuery, url, body)

議論のハイライト

  • 定数追加の是非: neild氏やapparentlymart氏からは「http.MethodGetは"GET"という文字列以上の情報を伝えず、コード生成ツールでの検索性もむしろ悪化する」として、定数追加自体に懐疑的な意見が出ました。一方でjub0bs氏は「HTTPメソッド名は大文字小文字を区別するため、定数はタイプミス防止に役立つ」と反論しています。
  • 既存定数を凍結すべきという提案: apparentlymart氏は「今後は新規定数を一切追加せず、net/http/v2では全定数を廃止すべき」と提案しましたが、EyJunge1氏は「QUERYだけを除外すると、標準化されたばかりの主要メソッドだけが欠けている状態になり、かえって混乱を招く」と反論しました。
  • 新規追加の判断基準: neild氏は「最新のHTTP RFC（RFC 9110）に記載されている、またはhttpbisのRFCで'Proposed Standard'以上のステータスを持つメソッド」を追加基準とする案を提示。これに従うとRFC 10008（httpbisのProposed Standard）に基づくQUERYは基準を満たすとされました。
  • 将来の自動承認ポリシーへの発展: neild氏は上記基準を満たす将来のメソッドについては「自動的に承認扱いとすべき」と提案しており、この点は本proposalの範囲に含まれるかどうか、apparentlymart氏から追加確認のコメントが出ています（別途の提案として扱われる可能性があります）。
  • v1/v2の切り分け: 定数の要否については議論が分かれつつも、「v1はすでにRFC由来の全メソッド定数を含める設計を選択しているため、v2など将来のバージョンで別の判断をすればよい」という着地点で一定の合意が形成されました。

関連リンク