HEAD：用于获取资源的元信息。HEAD方法与GET方法类似，都可以查询资源的元信息（放在HTTP Response的Header），但不会返回资源的表述。例如用于判断资源是否存在。
PATCH：用于修改资源。与PUT方法不同的是，PATCH方法只传输改动的部分资源表述，而PUT方法需要传输完整的资源表述。
4) 返回码REST使用HTTP返回码来表示请求的结果。如果使用规范的REST API，那么根据HTTP返回码就能确定很多信息。常见的HTTP返回码如下：
200（OK）：表示请求成功。
201（Created）：表示资源创建成功。
204（No content）：表示资源为空。
301（Moved Permanently）：表示资源的URI已永久性更改，需要在响应内容中获取新的URI。
302（Moved Temporarily）：表示资源的URI已临时性更改，需要在响应内容中获取新的URI。
400（Bad Request）：表示请求有问题，如参数错误等。
403（Forbidden）：表示鉴权不通过，没有权限访问该资源。
404（Not Found）：表示资源不存在。
405（Method Not Allowed）：表示该资源不支持当前的请求方法。
409（Conflict）：表示当前请求的某前置条件不符合。
500（Internal Server Error）：通用内部错误。
502（Bad Gateway）：网关错误，从上游服务器收到无效响应。
504（Gateway Timeout）：网关超时，在预期时间内没有收到上游服务器的响应。
……
还有其他HTTP返回码，可以参考HTTP标准。
只要使用了规范的REST架构风格，那么就可以根据HTTP的标准，做出明确的相应处理，无需另外制定私有协议了。既减少了私有协议的兼容性问题，又能作为标准适用于所有的RESTful架构。
5) 返回内容REST API的返回内容应该是资源的表述。
前面说过，同一个资源可以有多种不同格式的表述，如json格式和xml格式，所以返回内容应该是自描述的。也就是说，在HTTP响应的Header中，必须包含Content-type属性，如application/json、application/xml、text/html等。
另外，REST是“可编程”的Web服务，也就是说，程序可以根据REST API的返回内容，进行下一步的操作。例如，查询author资源，下一步可能是要查询该作者著作的book资源。所以，如果author资源的表述中包含了该作者著作book资源的URI，则客户端可以进行相应的操作。又如，查询某个地图资源，地图资源的表述中如果包含了各方向的相邻地图资源，则当客户端的鼠标移到屏幕边缘时，就可以获取到该方向上的地图资源了；或者地图资源的表述中包含景点、餐馆等资源URI，则可以进行相应的操作。
在表述中包含其他资源的URI实现了连通性。连通性可以作为客户端应用状态的状态引擎，引导客户端进行下一步的操作，带来了极大的便利。
6) 其他统一接口还有其他方面的原则，本文就不细讲了，感兴趣的朋友可以阅读Fielding的论文。
2. 无状态无状态约束条件是指两次请求之间不存在依赖关系，每一次请求都包含完整的状态信息。这里指的状态是指客户端与服务器之间通信交互的状态，与资源状态无关。
举个有状态的例子，为了查工资，需要先登录系统（第一次请求），再输入查询密码（第二次请求）。如果前面两次请求都通过了，那么调用查询接口则可以查询到工资；否则调用查询接口则报未鉴权的错误。查询工资接口的返回结果与前面两次请求的状态是关联的，所以是有状态的服务。
而无状态的服务，则直接调用查询工资接口，在请求中（一般在Header中）带有鉴权信息，若鉴权通过则可查询到工资，鉴权不通过则报错。该请求不依赖于任何前置请求，称为无状态。
REST使用无状态约束条件，确保了请求的独立性和简单性，减少了很多跨请求的状态维护成本。当然，带来的代价是每次请求可能需要传输冗余的信息。
3. 缓存缓存约束条件主要是用于改善网络的效率。缓存约束条件要求一个请求的响应中的数据被隐式地或显式地标记为可缓存的或不可缓存的。如果响应是可缓存的，那么客户端缓存就可以为以后的相同请求重用这个响应的数据，减少了网络交互，提高了效率、可伸缩性和用户感知的性能。
4. 客户端-服务器