HTTP Caching API: Client Caching Using Your Browser

This API allows developers to increase page load speed dramatically by adding HTTP caching abilities to their applications, which makes possible to use header-based negociation in whether or not to download content.

How does it work?

This simple API is an interplay of classes dedicated to a particular aspect of HTTP caching logic:

  1. CacheRequest: encapsulates caching-related communication between client and server. This class centralizes headers received from client, which will later on fall subject of validation. If malformed, their values will be ignored.
  2. CacheValidator: performs validation (deciding whether or not requested resource has changed) on CacheRequest to decide whether or not requested resource should be returned from cache. Since API cannot by itself build an etag / last modified date representation of a requested resource, it delegates that algorithm to a Cacheable interface developers must implement.
  3. Cacheable: implementation of this interface is based on the common sense idea any cacheable resource should have an ETAG and/or a last modified date representation. Both will be matched with client's conditional headers, if any, in order to check if resource has changed. At a fundamental level, this is all what validation is about.
  4. CacheResponse: encapsulates caching-related communication between server and client. This class centralizes headers to be sent by server back to client based on CacheValidator results. If validation finds out resource hasn't changed (etag / last modified date match), a 304 Not Modified status code SHOULD be immediately returned. Otherwise, server MUST continue script execution until it's able to produce a full body 200 OK response. In both cases, in order to maintain cache communication, response MUST contain headers collected by this class.

All classes inside API belong to namespace Lucinda\Caching!

How can I use it?

To learn how to install and use this API, follow this step-by-step guide!


Share