134. hx-push-url（hx-push-urlヘッダー：サーバー側からの履歴操作：住所の決定権をサーバーが持つ）

原理：結果に合わせたURLの後付け

処理の後で、URLを決めたい時がある

通常、URL を履歴に積むかどうかは HTML 側の hx-push-url="true" (112.) で決めます。しかし、中には「通信が終わってみるまで、どのURLにするか決められない」というケースがあります。 - 検索をした結果、「一つの商品しか見つからなかったので、その商品の詳細URLにしたい」。 - 新しく保存をした直後に、「新しく割り振られたIDを含んだURLにしたい」。

「hx-push-url（エイチエックス・プッシュ・ユーアールエル）」ヘッダーを使うと、サーバー側からレスポンスを返す瞬間に、「今のURLバーはこれに書き換えてね！」と後出しで指示することができます。

実践：動的に決定される「正しいURL」

1. サーバーからURLを指定する

新しいデータが作成された後、そのIDが付いたURLを押し込む例です。

/* サーバーからのレスポンス(ヘッダー) */
hx-push-url: /items/created-999

これにより、ブラウザのURLバーは瞬時に /items/created-999 に変わり、履歴にも保存されます。

2. 不要な時は「false」を送る

逆に、HTML側で hx-push-url="true" になっていても、サーバー側で「あ、エラーが出たからURLは変えないで」と思ったときは、hx-push-url: false を送ることで、履歴への保存をキャンセルさせることもできます。

3. ステップ・バイ・ステップ解説

「後から決まるURL」を探す: 作成完了後の画面、自動リダイレクトの手前、検索結果の絞り込みなど。
ヘッダーの送信: サーバープログラムで、計算が終わった直後にこのヘッダーをセットします。
確認: 通信前と通信後で、期待通りにURLバーの文字が変化しているかを確認します。

比較：html属性としての push-url vs ヘッダーとしての push-url

属性として指定 (`hx-push-url="true"`)

場所: HTML側。
性格: 「このボタンを押したら、(URLは未定だけど)とにかく履歴を積むぞ」という事前予約。

ヘッダーとして指定 (`hx-push-url: /abc`)

場所: サーバー側。
性格: 「処理が終わった今、このURLを正式な住所として認め、履歴に刻め」という事後承認。
利点: サーバーサイドの知識（IDの発行など）に基づいた、より正確なURL管理が可能。

まとめ：初心者のための「住所の最終決定」

hx-push-url ヘッダーは、サーバーとブラウザの間の「信頼」の証です。

URLは真実を語る: サーバーが知っている「現在の真実（正しいIDやパス）」をURLバーに反映させることで、ユーザーはいつでもその正確な場所をブックマークしたり、共有したりできるようになります。
ユーザー体験の向上: 画面が更新された瞬間にURLも「シュッ」と正しいものに変わる様子は、アプリとしての完成度の高さを感じさせます。
ロジックの集中: 複雑なURL生成をJavaScript(フロント)ではなく、得意な言語(サーバー)で集中して行えるため、プログラムが綺麗になります。

住所を確定させ、記録を刻む。hx-push-url ヘッダーという「後出しの決定権」を味方につけて、常に最新で正確なURLを提供し続ける、誠実なWebシステムを構築してください。次の記事では、これらのHTMLを効率よく生成するための「レンダリング戦略（135. Templating Strategies）」をご紹介します。