Implement server-side response cache

No files, tests, or entry points are named. Start by clarifying the cache scope, conditional-request behavior, provider interface, and supported backends, then trace the REST endpoint flow where responses and ETags are handled. Done means an agreed design and implementation plan with provider coverage and conformance tests defined.

This is a topic I've been burning to raise but there are still features required that takes a higher priority than this. Since the RESTful API architecture involves extensive CACHE considerations there is not much need to further motivate the benefit of having a properly implemented CACHE solution at the end-point, aside from the obvious performance and load shedding advantages, to be able to verify and test conformance of the developed REST implementation without the need for external CACHE providersp

It is only until now that we are discussing conditional requests that this has become pertinent as the framework will see a huge benefit if it is able to cache and make request provisioning decisions based on cached variants rather than re-requesting the Routers to populate a response on every request. for state information.

2616 allows for ETag to be used as an "opaque" identifier instead of dates:

The ETag response-header field value, an entity tag, provides for an "opaque" cache validator. This might allow more reliable validation in situations where it is inconvenient to store modification dates, where the one-second resolution of HTTP date values is not sufficient, or where the origin server wishes to avoid certain paradoxes that might arise from the use of modification dates.

Although I this will not be sufficient as the only identifier and we will benefit from having an additionally indexed key when ETag is not available, based on a calculated checksum of the following HTTP artifacts:
(Of the top of my head this will have to be verified)

• location

• accept header

• method

  In the interim it is safe to speculate that we would consider plug-able cache provisioning utilizing some/all of the following :

• via file cache - simple and free from dependencies utilizing PHPs file_put/file_get_contents();

• via PDO as database driven cache

• via APC provisioned

• via REDIS provisioned

• via Memcache provisioned

• via APC provisioned

• via Solr provisioned

• via ElasticSearch provisioned

• via Reverse Proxy (Squid probably) provisioned (not sure if this is exactly what we have in mind though.

Aside from the obvious requirement that the design should be flexible to easily cater for additions to this list of providers I would additionally see the functionality being transparently exposing an API that can be utilized by other components of the application where this functionality may be required without impacting the core cache.

What are your thoughts?