RESTful服务最佳实践——（十二）

缓存和可伸缩性

通过支持系统层级消除检索请求数据的远程调用，缓存提高了系统的可扩展性。服务通过在响应中设置头标志来提高缓存能力。不幸的是，缓存相关的头在HTTTP1.0中与HTTP1.1中不同，因此服务器要同时支持两种版本。下表表示的是支持GET请求缓存的必要最小头集合，并带有适当值的描述。

Http头文件	描述	例子
Date	响应返回的日期和时间（RFC1123格式）。	Date: Sun, 06 Nov 1994 08:49:37 GMT
Cache-Control	一个响应可被缓存的最大秒数（最大age值）。然而，如果响应不支持缓存，那么no-cache就是它的值。	Cache-Control: 360 Cache-Control: no-cache
Expires	如果给出了最大age值，包含响应期望的时间戳（RFC1123格式），则是日期+最大age的值。如果响应不支持缓存，那么头不存在。	Expires: Sun, 06 Nov 1994 08:49:37 GMT
Pragma	当Cache-Control为no-cache时，这个头也被设置为no-cahche。否则，不存在。	Pragma: no-cache
Last-Modified	资源本身被最后修改的时间戳（RFC1123格式）	Last-Modified: Sun, 06 Nov1994 08:49:37 GMT

为了简化，这里举一个响应中的头集合的例子。该响应对应一个对资源的简单GET请求，可以支持缓存一天（24小时）：

Cache-Control: 86400
Date: Wed, 29 Feb 2012 23:01:10 GMT
Last-Modified: Mon, 28 Feb 2011 13:10:14 GMT
Expires: Thu, 01 Mar 2012 23:01:10 GMT

下面是缓存被完全禁用的响应的类似例子：

Cache-Control: no-cache
Pragma: no-cache

ETAG 头文件

Etag头对验证缓存表征的时间性很有用，同时有助于条件的读取和更新操作（分别为GET和PUT）。对表征版本而言，它的值是一个任意字符串。然而，对于表征的不同格式，它也可以不同。Json格式响应的ETag与相同资源XML格式响应的ETag会不同。Etag头的值像带有格式的底层域对象的哈希表（例如java中的Obeject.hashcode()）一样简单。建议为每个GET（读）操作返回一个Etag头。另外，确保用双引号包含Etag的值，例如：

ETag: "686897696a7c876b7e"

---

原文如下

Caching and Scalability

Caching enhances scalability by enabling layers in the system to eliminate remote calls to retrieve requested data. Services enhance cache-ability by setting headers on responses. Unfortunately, caching-related headers in HTTP 1.0 are different than those in HTTP 1.1, so services should support both. Below is a table of minimal headers required to support caching for GET requests, along with a description of appropriate values.

Http Header	Description	Example
Date	Date and time the response was returned (in RFC1123 format).	Date: Sun, 06 Nov 1994 08:49:37 GMT
Cache-Control	The maximum number of seconds (max age) a response can be cached. However, if caching is not supported for the response, then no-cache is the value.	Cache-Control: 360 Cache-Control: no-cache
Expires	If max age is given, contains the timestamp (in RFC1123 format) for when the response expires, which is the value of Date (e.g. now) plus max age. If caching is not supported for the response, this header is not present.	Expires: Sun, 06 Nov 1994 08:49:37 GMT
Pragma	When Cache-Control is ‘no-cache’ this header is also set to ‘no-cache’. Otherwise, it is not present.	Pragma: no-cache
Last-Modified	The timestamp that the resource itself was modified last (in RFC1123 format).	Last-Modified: Sun, 06 Nov1994 08:49:37 GMT

To simplify, here’s an example header set in response to a simple GET request on a resource that enables caching for one day (24 hours):

Cache-Control: 86400
Date: Wed, 29 Feb 2012 23:01:10 GMT
Last-Modified: Mon, 28 Feb 2011 13:10:14 GMT
Expires: Thu, 01 Mar 2012 23:01:10 GMT

And below is an example of a similar response that disables caching altogether:

Cache-Control: no-cache
Pragma: no-cache

The ETag Header

The ETag header is useful for validating the freshness of cached representations, as well as helping with conditional read and update operations (GET and PUT, respectively). Its value is an arbitrary string for the version of a representation. However, it also should be different for each format of a representation—the ETag for a JSON response will be different for the same resource represented in XML. The value for the ETag header can be as simple as a hash of the underlying domain object (e.g. Object.hashcode() in Java) with the format included in the hash. It is recommended to return an ETag header for each GET (read) operation. Additionally, make sure to surround the ETag value in double quotes. For example:

ETag: "686897696a7c876b7e"