PHPackages                             fideloper/resourcecache - PHPackages - PHPackages  [Skip to content](#main-content)[PHPackages](/)[Directory](/)[Categories](/categories)[Trending](/trending)[Leaderboard](/leaderboard)[Changelog](/changelog)[Analyze](/analyze)[Collections](/collections)[Log in](/login)[Sign up](/register)

1. [Directory](/)
2. /
3. fideloper/resourcecache

ActiveLibrary

fideloper/resourcecache
=======================

Handle HTTP validation Caching using If-\* Headers

7361PHP

Since Jun 10Pushed 12y ago2 watchersCompare

[ Source](https://github.com/fideloper/ResourceCache)[ Packagist](https://packagist.org/packages/fideloper/resourcecache)[ RSS](/packages/fideloper-resourcecache/feed)WikiDiscussions master Synced 2mo ago

READMEChangelogDependenciesVersions (2)Used By (0)

Resource Cache
==============

[](#resource-cache)

**Note 1:** This library is functionally similar to Symfony's built-in [Validation Cacheing](http://symfony.com/doc/2.0/book/http_cache.html#index-10) code. Specifically, Symfony handles Conditional GETs. This library also handles Concurrency Control. Both Conditional GETs and Concurrency Control paradigms use ETags or Last-Modified dates.

**Note 2:** I've re-written this library in an implementation I like better. See my [ConditionalRequest](https://github.com/fideloper/ConditionalRequest) library/package. This new package still encapsulates some business logic that Symfony's HttpCache package has, but builds on it a bit. Namely, both have Conditional GET support. ConditionalRequest also includes Concurrency Control using the same paradigms.

The Situation
-------------

[](#the-situation)

Frameworks don't often give you tools to control HTTP caching, such as setting ETags or Last-Modified dates.

Goals
-----

[](#goals)

This package aims to give you cache control. It's goals are:

1. Allow Validation Caching (using ETags with If-Match,If-None-Match, Last-Modified with If-Modified, If-Unmodified, and so on)
2. Allow Expiration Caching (Using Expires, Last-Modified, Cache-Control and possibly Pragma headers)
3. Help developers learn about HTTP and Caching, a topic which is often ignored

Installation
------------

[](#installation)

[![Build Status](https://camo.githubusercontent.com/743fec7b6d54e8a61eb90bd51c4961bc3d565a509b5177dc049e725535b272d2/68747470733a2f2f7472617669732d63692e6f72672f666964656c6f7065722f5265736f7572636543616368652e706e673f6272616e63683d6d6173746572)](https://travis-ci.org/fideloper/ResourceCache)

This is a Composer package, available on Packagist.

To install it, edit your composer.json file and add:

```
{
    "require": {
        "fideloper/resourcecache": "dev-master"
    }
}
```

If you are installing this into `Laravel 4`, you then need to add in the Service Provider. To do so, open up `app/config/app.php`, and add this entry with the other Service Providers.

```
# File: app/config.app.php
'providers' => array(

    ...other providers...

    'Fideloper\ResourceCache\ResourceCacheServiceProvider',

),
```

Usage
-----

[](#usage)

There are two steps:

1. Implementing the Resource interface (This is done for you if you're using Laravel 4)
2. Using the ResourceRequest and ResourceResponse classes with your Resource

### Implement a Resource Interface

[](#implement-a-resource-interface)

This package contains a Request Interface and Response Interface. These should be implemented to your specific needs. For example, for Laravel 4, which uses Symfony Request/Response classes, I've created a Symfony implementation for each.

You must implement:

1. `Fideloper\ResourceCache\Http\ResourceInterface`
2. `Fideloper\ResourceCache\Http\ResponseInterface`
3. `Fideloper\ResourceCache\Resource\ResourceInterface`

Example implementations can be found [in the wiki](https://github.com/fideloper/ResourceCache/wiki/Implementation-Explanation).

### Using your Request/Response and Resource classes

[](#using-your-requestresponse-and-resource-classes)

Once you have an implementation put together, you can use them in your controller. You can see examples of that [here](https://github.com/fideloper/ResourceCache/wiki/Implementation-Explanation#using-resource-responserequest-with-a-resource).

Some Explanation
----------------

[](#some-explanation)

There are a few types of caching:

1. In-app caching (Memcache, Redis, other memory stores)
2. HTTP caching - gateway, proxy and private (aka browsers, and similar)

Making a response (web page, api-response, etc) cachable by third-parties is part of the HTTP cache mechanisms. Which cache mechanisms you use depends on your use case.

The HTTP spec defines 2 methods of HTTP caching:

1. **Validation** - save bandwidth by not having an origin server reply with a full message body (header-only response)
2. **Expiration** - to save round-trips to the origin server - a cache can potentially serve a response directly, saving the origin server from even knowing about the request

Validation caching, done with if-\* headers (if-match, if-modified-since, and so forth) is useful for 2 things (most useful for an API, in my opinion).

1. **Conditional GET requests** - a server can tell the request 'nothing has changed since you last checked'. This is good for mobile APIs where the bandwidth of re-sending a message body can be saved via conditional requests.
2. **Concurrency Control** - in a POST or, more likely, PUT request, a server can check if the resource being updated was changed since the requester last checked (solves the [Lost Update Problem](http://www.w3.org/1999/04/Editing/)). This is good for APIs with a lot of writes (updates) to resources.

Expiration caching, done with Expires, Cache-Control, Last-Modified and other headers, can aid in caching a response for the next user (or even for one specific user), saving your server(s) from some traffic load

1. If you have a gateway cache such as Varnish, you can potentially cache responses to end points per user A gateway cache gives you a lot of cache control since its part of your stack.
2. Setting your responses to being 'public' both in terms of cache control and authentication will allow Proxy caches to cache your site content
3. Requests behind authentication and/or SSL are usually not cached. You may be able to with a gateway cache, or with a private cache (aka, your client can figure out caching based on your expiration headers).

###  Health Score

23

—

LowBetter than 27% of packages

Maintenance20

Infrequent updates — may be unmaintained

Popularity14

Limited adoption so far

Community9

Small or concentrated contributor base

Maturity43

Maturing project, gaining track record

 Bus Factor1

Top contributor holds 100% of commits — single point of failure

How is this calculated?**Maintenance (25%)** — Last commit recency, latest release date, and issue-to-star ratio. Uses a 2-year decay window.

**Popularity (30%)** — Total and monthly downloads, GitHub stars, and forks. Logarithmic scaling prevents top-heavy scores.

**Community (15%)** — Contributors, dependents, forks, watchers, and maintainers. Measures real ecosystem engagement.

**Maturity (30%)** — Project age, version count, PHP version support, and release stability.

### Community

Maintainers

![](https://www.gravatar.com/avatar/5ffe7f19bdf080aaa14107239624d682f2e1b139b9459e93b56966649a4d7873?d=identicon)[fideloper](/maintainers/fideloper)

---

Top Contributors

[![fideloper](https://avatars.githubusercontent.com/u/467411?v=4)](https://github.com/fideloper "fideloper (41 commits)")

### Embed Badge

![Health badge](/badges/fideloper-resourcecache/health.svg)

```
[![Health](https://phpackages.com/badges/fideloper-resourcecache/health.svg)](https://phpackages.com/packages/fideloper-resourcecache)
```

PHPackages © 2026

[Directory](/)[Categories](/categories)[Trending](/trending)[Changelog](/changelog)[Analyze](/analyze)