Laravel API パフォーマンスの最適化: ETag と条件付きヘッダーを使用したキャッシュ
フロントエンドとバックエンドを分けてアプリケーションを作成する場合、バックエンドからデータを再度取得するためにフロントエンド クライアントが API にどのようなリクエストを送信するかを考え始める必要があります。フロントエンド キャッシュが追加されたデータをリアルタイムで更新できるかどうかを確認したいだけの場合でも。上記の要件に基づいて、ETag
ヘッダーと条件付きリクエストを使用できます。
このブログ投稿では、ETag
、If-None-Match
、If-Match
が行うことなどについて簡単に説明します。次に、これらをパッケージに適用する方法を見てみましょう。これにより、アプリケーションにすぐに実装できます。
肝心の ETag
ヘッダーから始めましょう。このヘッダーは、応答本文の正確な状態を表す値です。多くの場合、ETag
の値はコンテンツの hash
値になります。これは、応答データの一意の識別子を生成して保証する最も簡単な方法であるためです。
ETag
ヘッダーを確実に利用できるようにするには、条件付きリクエストを使用する必要があります。設定する必要がある最初の条件は、If-None-Match
ヘッダーです。これは、GET
の要求ヘッダーです。バックエンドがこのヘッダーを受信した後、現在のコンテンツと比較する必要があります。値が一致した場合はステータスコード304
のみが返されるため、エンティティリソースの取得に比べて応答結果データ自体は非常に小さいです。これらはすべて非常に簡単に実装できます。リソースを取得するための最初の GET
リクエストが ETag
データを返した場合、ブラウザは自動的にリクエスト設定 If-None-Match
ヘッダー。
これは、バックエンドが etag
と if-none-match
を実装するだけであれば、API からフロントエンドの量に転送されるデータを削減できることを意味します。
2 番目のリクエスト条件では、if-match
ヘッダーを使用します。これは、空中衝突を防ぐために使用されます。平たく言えば、バックエンドのデータを更新したいが、フロントエンドのデータが古い場合、バックエンドの更新を終了し、フロントエンドにリマインダーを表示する必要があります。これは、if-none-match
の仕組みと似ています。 ETag
値を含むリソースを取得した後、PATCH
リクエストを送信し、以前に受け取った ETag
値に等しい を設定できます。
値と一致します。次に、バックエンドは、サーバー上で現在利用可能なリソースの etag
値が、送信したリソースと一致するかどうかを確認します。一致するものがあれば、更新が許可されます。一致しない場合は、条件が一致しないことをフロントエンドに知らせるために 412
ステータス コードが返されます。
この条件付きリクエスト プラグイン パッケージを laravel
プロジェクトで使用する場合は、次のコマンドを使用してインストールできます:
$ composer require werk365/etagconditionals
次に、etag
ミドルウェアをルートに追加すると、それを使用できるようになります。ミドルウェアの仕組みを学びたい方、プラグインパッケージを使わずにこの機能を実装したい方は、ぜひ読んでください。
ご想像のとおり、この機能はミドルウェアを介して簡単に実装できます。 Laravel
は実際には、ETag
ヘッダーを設定するための SetCacheHeaders
ミドルウェアを提供しますが、HEAD
リクエストはサポートしていません。 SetEtag
ミドルウェアの内容は次のようになります:
public function handle(Request $request, Closure $next) { // Handle request $method = $request->getMethod(); // Support using HEAD method for checking If-None-Match if ($request->isMethod('HEAD')) { $request->setMethod('GET'); } //Handle response $response = $next($request); // Setting etag $etag = md5($response->getContent()); $response->setEtag($etag); $request->setMethod($method); return $response; }
最初に行う必要があるのは、要求されたメソッドを変更する場合に備えて、それを取得することです。次に、HEAD
リクエストを処理するときに、リクエストされたコンテンツがロードされ、暗号化できることを確認するために、このリクエストを GET
リクエストに変更します。この後、md5()
メソッドを使用して暗号化された応答本文のコンテンツにジャンプします。応答を返す前に、暗号化された hash
値を ETag
ヘッダーとして使用し、元のリクエスト メソッドを設定し直します。
これは、もう 1 つの比較的単純な方法です。まずコードを見てみましょう:
public function handle(Request $request, Closure $next) { // Handle request $method = $request->getMethod(); // Support using HEAD method for checking If-None-Match if ($request->isMethod('HEAD')) { $request->setMethod('GET'); } //Handle response $response = $next($request); $etag = '"'.md5($response->getContent()).'"'; $noneMatch = $request->getETags(); if (in_array($etag, $noneMatch)) { $response->setNotModified(); } $request->setMethod($method); return $response; }
这个开头与 SetEtag
中间件相似,将确保我们可以再次处理 HEAD
请求,并根据响应内容生成 hash值。注意这种情况下我们需要将hash值用双引号包裹。双引号包裹 ETag
头,然后在setEtag中间件中 setEtag()
方法自动包裹hash。有了hash值后,我们可以轻松的与 If-None-Match
头进行比较。由于该头可以自动加载无限个hash,并且 getETags()
方法会将它们以数组形式返回,所以我们可以核对新生成的值是否存在于数组中。如果确实有匹配,我们可以在响应中使用 setNotModified()
设置 304
的状态码。
处理 If-Match
将稍微复杂一些。这个问题归结于:我们需要找到一种方法,用来获取应该更新的当前版本的内容。这可以用多种方式实现。
GET
请求GET
请求( 例如,调用控制器上的 show()
方法)GET
请求。在构建这个中间件时,我开始尝试使用第二个选项。出于某种原因,这对我来说似乎是最好的选择。我成功地创建了一个完全可以工作的版本,但我对结果并不满意。为了让它工作,我需要做一些假设,预设一些限制,并做了太多的工作,而我只需要创建一个新的请求就可以了。
当我们要发起一个新的请求来获取当前版本资源的时候,代码是下面这样的:
public function handle(Request $request, Closure $next) { // 只有请求方式是 PATCH 并且已经设置了 If-Match 头 if (! ($request->isMethod('PATCH') && $request->hasHeader('If-Match'))) { return $next($request); } // 对同一个点创建新的 GET 请求, // 复制和添加请求头,让中间件能忽略本次请求 $getRequest = Request::create($request->getRequestUri(), 'GET'); $getRequest->headers = $request->headers; $getRequest->headers->set('X-From-Middleware', 'IfMatch'); $getResponse = app()->handle($getRequest); // Get content from response object and get hashes from content and etag $getContent = $getResponse->getContent(); $getEtag = '"'.md5($getContent).'"'; $ifMatch = $request->header('If-Match'); // 比较当前和请求携带的 hash 值 if ($getEtag !== $ifMatch) { return response(null, 412); } return $next($request);
所有这些中间件都将在请求生命周期开始时运行。首先,我们将过滤掉任何非 PATCH
请求或请求头中没有 If Match
的请求。之后,我们将向同一个端点发出一个新的 GET
请求,并从原来的请求中复制请求头,以便新请求可以通过身份验证中间件和其他约束。
使用这个新请求的响应,我们将再次生成一个哈希,以便与发送的哈希进行比较。如果哈希匹配,请求将被中间件允许通过。如果不匹配,将返回状态代码为 412
的请求响应。
通过使用这三个中间件,你可以在你的 Laravel 应用程序中轻松处理 ETag 和条件请求。
软件包:https://github.com/365Werk/etagconditionals
原文地址:https://hergen.nl/caching-your-laravel-api-with-etag-and-conditional-requests
译文地址:https://learnku.com/laravel/t/55539
以上がETagと条件付きヘッダーをキャッシュに使用する方法の詳細な説明の詳細内容です。詳細については、PHP 中国語 Web サイトの他の関連記事を参照してください。