REST 本身是设计风格而不是标准。REST 谈论一件非常重要的事，如何正确地使用 Web标准，例如，HTTP 和 URI。想要了解 REST 最好的方式就是思索与了解 Web 及其工作方式。如果你设计的应用程序能符合 REST 原则 (REST principles)，这些符合 REST 原则的 REST 服务可称为 "RESTful web service" 也称 "RESTful Web API"。"-ful" 字尾强调它们的设计完全符合 REST 论文里的建议内容。
最佳实践：更好的设计你的 REST API
REST API 设计在细节上有很多自己独特的需要注意的技巧，并且对开发人员在构架设计能力上比传统 API 有着更高的要求。本文通过翔实的叙述和一系列的范例，从整体结构，到局部细节，分析和解读了为了提高易用性和高效性，REST API 设计应该注意哪些问题以及如何解决这些问题。
由于 REST 可以降低开发的复杂度，提高系统的可伸缩性，增强系统的可扩展性，简化应用系统之间的集成，因而得到了广大开发人员的喜爱，同时得到了业界广泛的支持。比 如 IBM，Google 等公司的很多产品都提供了 REST API 给开发人员；与此同时，大量的开源项目和云计算服务都提供了 REST API 接口。
而在最近，一些新产品的开发甚至已经几乎完全抛弃了传统的类似 JSP 的技术， 转而大量使用 REST 风格的构架设计， 即在服务器端所有商业逻辑都以 REST API 的方式暴露给客户端， 所有浏览器用户界面使用 widget，Ajax，HTML5 等技术，用 HTTP 的方式与后台直接交互。
那么， 在 REST API 爆炸式增长的今天， 我们应该如何更好的设计我们的接口， 来提高我们的 API 的可用性，易用性，可维护性与可扩展性呢？本文将从以下方面与您探讨 REST API 设计方面的最佳实践：
如何规划资源标识结构与 URI 模式
如何根据应用场景提供内容协商
如何正确的使用 HTTP 响应代码
如何处理缓存和并发请求
如何利用数据冗余和链接元素
先决条件如果您具有如下知识与经验，，将有助于您阅读和理解本文章的内容
理解和使用内容协商我们的开发者在发送一个 REST API 请求的同时，根据应用场景，针对相同的资源，可能会期待不同的返回形式。
比如，我希望根据用户客户端语言，同一个资源的内容可以返回不同的语言。又比如，当我使用 Java 编程的时候，我希望得到 ATOM 格式的返回结果，而当我使用 JavaScript 编程的时候，我希望得到 Json 格式的返回结果。
因此，我们在设计 REST API 的时候，应该提供完备的内容协商能力。
使用 URL 参数进行内容协商最容易想到的自然是通过 URL 参数进行控制，我们经常看到形如 / 航班号 /entry? format=JSON 这样的 URL。这种方式的优势就是简单灵活， 你可以通过任何 URL 参数来组合你的输出格式。
下面是一个来自 IBM developerWorks 的 API 样例，尝试请求该 API，你可以看到该集合是如何支持不同的输出格式请求的。
清单 3. IBM developerWorks 的文件服务标签云的 APIREST API 请求，要求返回 XML 格式数据： GET https://www.ibm.com/developerworks/mydeveloperworks /files/form/anonymous/api/tags/feed?format=xml &scope=document&pageSize=30&sK=cloud&sO=dsc REST API 请求，要求返回 JSON 格式数据： GET https://www.ibm.com/developerworks/mydeveloperworks /files/form/anonymous/api/tags/feed?format=json &scope=document&pageSize=30&sK=cloud&sO=dsc
使用 Accept 头进行内容协商使用 URL 参数，简单灵活，但是也由此带来了设计上的随意和不标准。并且，过多的参数会导致 URL 的可读性变差，更有甚者，可能会导致 URL 过长，超出规范，API 请求无法执行。
更 为标准的内容协商方式是使用 HTTP 头。我们通常使用 Accept 来设置我们接受的返回结果的内容格式，用 Accept-Charset 来设置字符集，用 Accept-Encoding 来设置数据传输格式，用 Accept-Language 来设置语言。
使用 URI 模式进行内容协商还有一种模式，就是将协商设置直接作为 URI 的一部分，将不同的返回视为不同的资源，比如 / 航班号 /json 来返回 JSON 格式的结果，用 / 航班号 /atom 来返回 ATOM 格式的结果。
正确的使用 HTTP 响应代码作为 API 的设计者，正确的将 API 执行结果和失败原因用清晰简洁的方式传达给客户程序是十分关键的一步。 我们确实可以在 HTTP 的相应内容中描述是否成功，如果出错是因为什么， 然而， 这就意味着用户需要进行内容解析，才知道执行结果和错误原因。因此，HTTP 响应代码可以保证客户端在第一时间用最高效的方式获知 API 运行结果，并采取相应动作。 下表列出了比较常用的响应代码。
表 1. 常用 HTTP 响应代码含义 HTTP 响应代码代码含义200 已创建，请求成功且服务器已创建了新的资源。
201 是否只显示处于警告状态的应用实例
301 重定向 , 请求的网页已被永久移动到新位置。服务器返回此响应时，会自动将请求者转到新位置。
302 重定向 , 请求的网页临时移动到新位置，但求者应继续使用原有位置来进行以后的请求。302 会自动将请求者转到不同的临时位置。
304 未修改，自从上次请求后，请求的网页未被修改过。服务器返回此响应时，不会返回网页内容。
400 错误请求 , 服务器不理解请求的语法。
401 未授权 , 请求要求进行身份验证。
403 已禁止 , 服务器拒绝请求。
404 未找到 , 服务器找不到请求的网页。
405 方法禁用 , 禁用请求中所指定的方法。
406 不接受 , 无法使用请求的内容特性来响应请求的网页。
408 请求超时 , 服务器等候请求时超时。
410 已删除 , 如果请求的资源已被永久删除，那么，服务器会返回此响应。
412 未满足前提条件 , 服务器未满足请求者在请求中设置的其中一个前提条件。
415 不支持的媒体类型 , 请求的格式不受请求页面的支持。
500 内部服务器错误。
使用 HTTP 头处理缓存和并发
缓存和并发处理，从来是大型软件系统设计中的重要组成部分。
使用 HTTP 头进行缓存处理