このページには、Inertiaプロトコルの詳細な仕様が記載されています。概要については、まず 動作原理のページをお読みください。
Inertiaアプリケーションへの最初のリクエストは、特別なInertiaヘッダーやデータのない、通常のフルページブラウザリクエストです。これらのリクエストに対して、サーバーは完全なHTMLドキュメントを返します。
このHTMLレスポンスには、サイトのアセット（CSS、JavaScript）と、ページの本文にあるルート<div>が含まれています。ルート<div>はクライアントサイドアプリケーションのマウントポイントとして機能し、 data-page属性には、最初のページのJSONエンコードされたページオブジェクトが含まれています。Inertiaはこの情報を使用して、クライアントサイドフレームワークを起動し、最初のページコンポーネントを表示します。
<html>
<head>
<title>My app</title>
<link href="/css/app.css" rel="stylesheet">
<script src="/js/app.js" defer></script>
</head>
<body>
<div id="app" data-page='{"component":"Event","props":{"event":{"id":80,"title":"Birthday party","start_date":"2019-06-02","description":"Come out and celebrate Jonathan's 36th birthday party!"}},"url":"/events/80","version":"c32b8e4965f418ad16eaebba1d4e960f"}'></div>
</body>
</html>Inertiaアプリケーションが起動したら、サイトへの後続のリクエストは、 X-Inertiaヘッダーがtrueに設定されたXHRを使用して行われます。このヘッダーは、リクエストがInertiaによって行われ、標準的なフルページアクセスではないことを示します。
サーバーがX-Inertiaヘッダーを検出すると、完全なHTMLドキュメントを返す代わりに、エンコードされたページオブジェクトを含むJSONレスポンスを返します。
{
"component": "Event",
"props": {
"event": {
"id": 80,
"title": "Birthday party",
"start_date": "2019-06-02",
"description": "Come out and celebrate Jonathan's 36th birthday party!"
}
},
"url": "/events/80",
"version": "c32b8e4965f418ad16eaebba1d4e960f"
}Inertiaは、ページオブジェクトを介してサーバーとクライアント間でデータの共有を行います。このオブジェクトには、ページコンポーネントのレンダリング、ブラウザの履歴状態の更新、サイトのアセットバージョンの追跡に必要な情報が含まれています。ページオブジェクトには、次の4つのプロパティが含まれています。
標準的なフルページアクセスでは、ページオブジェクトはルート<div>のdata-page属性にJSONエンコードされます。Inertiaアクセスでは、ページオブジェクトはJSONペイロードとして返されます。
シングルページアプリケーションにおける一般的な課題の1つは、サイトのアセットが変更された場合にそれらを更新することです。Inertiaは、サイトのアセットの現在のバージョンを追跡することで、これを容易にします。アセットに変更があった場合、Inertiaは自動的にXHRアクセスではなくフルページアクセスを行います。
Inertiaのページオブジェクトには、version識別子が含まれています。このバージョン識別子はサーバーサイドで設定され、数値、文字列、ファイルハッシュ、またはサイトのアセットの現在の「バージョン」を表すその他の値にすることができます（サイトのアセットが更新されると値が変更される限り）。
Inertiaリクエストが行われるたびに、Inertiaは現在の資産バージョンを X-Inertia-Versionヘッダーに含めます。サーバーがリクエストを受け取ると、X-Inertia-Versionヘッダーで提供された資産バージョンと現在の資産バージョンを比較します。これは通常、サーバーサイドフレームワークのミドルウェアレイヤーで処理されます。
資産バージョンが同じ場合、リクエストは期待通りに続行されます。ただし、資産バージョンが異なる場合、サーバーはすぐに409 Conflictレスポンスを返し、URLを X-Inertia-Locationヘッダーに含めます。このヘッダーは、サーバーサイドのリダイレクトが発生する可能性があるため必要です。これにより、Inertiaは最終的な目的のURLがわかります。
注：409 ConflictレスポンスはGETリクエストに対してのみ送信され、 POST/PUT/PATCH/DELETEリクエストに対しては送信されません。ただし、これらのリクエストの後にGETリダイレクトが発生した場合には送信されます。
409 Conflictレスポンスが発生したときに「フラッシュ」セッションデータが存在する場合、Inertiaのサーバーサイドフレームワークアダプターは自動的にこのデータを再フラッシュします。
Inertiaリクエストを行う際、部分的な再読み込みオプションを使用すると、同じページコンポーネントへの後続のアクセス時に、サーバーからプロップス（データ）のサブセットを要求できます。これは、一部のページデータが古くなっても問題ない場合に役立つパフォーマンス最適化です。
部分的な再読み込みリクエストが行われると、Inertiaはリクエストにさらに2つのヘッダーを含めます。 X-Inertia-Partial-Data および X-Inertia-Partial-Component。
X-Inertia-Partial-Data ヘッダーは、返されるべきプロパティ（データ）キーのカンマ区切りリストです。
X-Inertia-Partial-Component ヘッダーには、部分的に再読み込みされるコンポーネントの名前が含まれています。これは、部分的な再読み込みが同じページコンポーネントへのリクエストに対してのみ機能するため必要です。何らかの理由で最終的な宛先が異なる場合（例：ユーザーがログアウトされ、ログインページに移動した場合）、部分的な再読み込みは行われません。
{
"component": "Events",
"props": {
"auth": {...}, // NOT included
"categories": [...], // NOT included
"events": [...] // included
},
"url": "/events/80",
"version": "c32b8e4965f418ad16eaebba1d4e960f"
}