C# での Web アプリ開発で、要求 URL 中のクエリ文字列をいい感じに読み取る - 特に Blazor WebAssembly (とりわけ .NET 5 以前) での注意点

C# による Web アプリケーション開発における話題。
とりわけタイトルの件を、自分の備忘録的に本ブログにメモする回。

近代の C# (.NET) による Web アプリケーション開発においては、要求 URL 中のクエリ文字列を自前のコードで読み取ることは、まず滅多に発生しない。

大抵の場合は、フレームワーク側でクエリ文字列中の値を何かしらデータバインディング的な方式で変数等に格納済みにしてくれる。
なので、我々アプリケーション開発者はそれを扱うのが一般的だ。

C# で SPA を実装できる Blazor においても、.NET 6 以降であれば、要求 URL 中に含まれるクエリ文字列をパラメータ用プロパティにバインドできるようになった (詳細は下記参照)。

HttpUtility.ParseQueryString

しかし希とは言え、フレームワークに頼れず、生の要求 URL 文字列からそれに含まれるクエリ文字列を読み取る必要が発生することはある (Blazor の .NET 5 かそれより前の世代であるとか)。

そんな場合、ネットで検索すればすぐに解法が見つかるが、System.Web 名前空間にある HttpUtility クラスの ParseQueryString() 静的メソッドを使えば良い (下記が公式ドキュメント)。

Blazor 上での利用の場合、実際の使い方は以下のような感じだろう (NavigationManager を inject したコンポーネント中での利用例)。

@using System.Web

...

var uri = new Uri(this.NavigationManager.Uri);

var queryStrings = HttpUtility.ParseQueryString(uri.Query);

// 👇 要求 URL が "http://...?foo=bar" なら "bar" が返る。

//    要求 URL にクエリ文字列 "foo" が無ければ null が返る。

var foo = queryStrings["foo"];

UriExtensions.ParseQueryString

ということで、C# における Web アプリケーション実装において、要求 URL 中のクエリ文字列を読み取るには、 HttpUtility.ParseQueryString を使うのがまずは正解である。

しかしところで、実は、UriExtensions.ParseQueryString() という、こちらは Uri クラスに対する拡張メソッドも存在していたりする。
だが、先に言っておくと、自分の見解としては、こちらは今となっては使用はお勧めしない (詳細は後述)。

そうは言いつつも、いちおう使い方を示しておくと、以下の様になる (先と同じく、Blazor アプリにおける、NavigationManager を inject したコンポーネント中での利用例)。

var uri = new Uri(this.NavigationManager.Uri);

var queryStrings = uri.ParseQueryString();

var foo = queryStrings["foo"];

機能的には最初に紹介した HttpUtility.ParseQueryString と同じ。
構文上は、この拡張メソッド版のほうがいくぶんすっきりするかな、といったところである。

さて、この拡張メソッド版 UriExtensions.ParseQueryString() の利用をなぜお勧めしないかというと、実装が古くなりつつあるからだ。
一例を挙げよう。

UriExtensions クラスには、ParseQueryString 拡張メソッド以外にも、TryReadQueryAs<T> や TryReadQueryAsJson など、クエリ文字列を何かしらオブジェクトにバインドする便利な拡張メソッドが用意されている。しかしそのせいだろう、Json.NET (Newtonsoft.Json) に依存しているのである。

いや、Json.NET (Newtonsoft.Json) への依存が必ずしも悪いというわけではない。

しかしながら、大方のユースケースは System.Text.Json で賄えるようになった昨今、とりわけブラウザにダウンロードされる総コンテンツサイズが気になる Blazor WebAssembly においては、追加で Json.NET (Newtonsoft.Json) のアセンブリの読み込みを要するのは、個人的にはあまりお勧めしかねる次第である。

ちなみに、最初の HttpUtility.ParseQueryString() を使った実装例と、Json.NET (Newtonsoft.Json) への依存を含む UriExtensions.ParseQueryString() を使った実装例とでは、Blazor WebAssembly のデバッグビルドの場合、ダウンロードコンテンツサイズは 約 400 KB 程増える結果となった。

もっとも、この 400KB 増を大きい見るか大したことない見るか、案件次第であったりするので、一概にはどうこう言えないところではある。
(※あと、これはデバッグビルドにおける比較結果なので、発行時は ILリンカの効果によって差はもっと縮まる可能性はある。)

その他の理由として、この UriExtensions クラスを収録している NuGet パッケージ Microsoft.AspNet.WebApi.Client (下記リンク) であるが、2018年11月を最後に更新がない。

公式ドキュメント (下記リンク) のほうも、更新は凍結された模様だ。

以上のことから、UriExtensions クラスの使用はお勧めしかねる、というのが自分の見解だ。

それでも UriExtensions を使う場合... パッケージ参照に注意!

しかし諸般の事情から、UriExtensions クラスを利用する必要に迫られることがあるかもしれない (ParseQueryString はともかく、TryReadQueryAsJson が使いたい、とか?)。

そんな場合、参照追加する NuGet パッケージに注意されたい。

前述のとおり、 UriExtensions クラスの収録パッケージは Microsoft.AspNet.WebApi.Client が公式である。

いっぽうで、UriExtensions クラスの棲息アセンブリを見てみると、(上記公式ドキュメントにも記載があるが) System.Net.Http.Formatting.dll となっている。

UriExtensions クラスの収録 NuGet パッケージの前提知識なく、この情報のみを手がかりに nuget.org で "System.Net.Http.Formatting" で検索すると "System.Net.Http.Formatting.Extension" という名前の NuGet パッケージが見つかるのだ。

しかしこの "System.Net.Http.Formatting.Extension" というパッケージ、(.NET IL 的には問題ないとしても) .NET Framework 4 用となっているし、最終リリースが 2015 年である。

そもそもどうにも Microsoft 公式のパッケージには見えない。
 (その割にダウンロード数は 1万近いし、他のたくさんの NuGet パッケージから参照されていたり、Microsoft の AI ラボの GitHub リポジトリからも参照されていたりと謎が多いように感じられる...)

以上のことから、"System.Net.Http.Formatting.Extension" というパッケージは使わないのがよかろう、というのが自分見解である。

まとめ

後半、ぐだぐだ書いたが、結論は (少なくとも本記事投稿時点では) 要求 URL 中のクエリ文字列を直接解析する必要に迫られたら、
「HttpUtility.ParseQueryString() 使おう、他は使わない」
のがお勧め、ということである。

One more thing....

...と、まとめておいて何だが、最後にもうひとつ。

クエリ文字列の解析については最新の動向 (?) として下記 Issue を見つけた。
今のところは公開 API ではないようなのだが、引き続き要注目である。