REST代表表述性状态转移，这是Roy Fielding在2000年创造的一个术语。它是一种用于设计网络上松耦合应用程序的架构风格，常用于Web服务的开发。
REST并不强制规定在底层应如何实现，它只提供高层设计指南，让我们自行考虑具体的实现方式。
在我上一份工作中，我为一家大型电信公司设计了两年优秀的RESTful API。在这篇文章中，我将分享除标准设计实践之外的想法。你可能在某些观点上与我意见不一，这完全没问题。我乐于以开放的心态与你讨论任何事情。
我们先从标准的设计细节开始，明确“Roy Fielding”希望我们构建的内容。然后，我会分享我的想法，这些想法将更侧重于你在设计RESTful API时需要注意的细节。
架构约束
REST定义了6个架构约束，使任何Web服务都成为一个真正的RESTful API。
统一接口
客户端-服务器
无状态
可缓存的
分层系统
按需代码（可选）
- 统一接口
由于约束名称本身适用，您必须为系统内暴露给API消费者的资源确定API接口，并严格遵守。系统中的资源应只有一个逻辑URI，并且该URI应提供一种获取相关或附加数据的方式。将资源与网页同义化总是更好的选择。
任何单一资源都不应过大，且在其表示中不应包含所有内容。在相关的情况下，资源应包含指向相对统一资源标识符（URI）的链接（HATEOAS），以获取相关信息。
此外，整个系统中的资源表示应遵循特定的准则，如命名约定、链接格式或数据格式（XML和/或JSON）。
所有资源都应可通过HTTP GET等通用方法访问，并使用一致的方法进行类似修改。
一旦开发人员熟悉了你的某个API，他应该能够采用类似的方法来处理其他API。
- 客户端-服务器
这一约束本质上意味着客户端应用程序和服务器应用程序必须能够独立发展，互不依赖。客户端只需知道资源URI即可。如今，这在Web开发中是标准做法，因此您无需做任何特殊处理。保持简单就好。
只要服务器和客户端之间的接口不变，它们就可以独立开发或替换。
- 无国籍
罗伊·菲尔丁（Roy Fielding）从HTTP中汲取了灵感，因此这一理念也体现在了这一约束中。他主张所有客户端与服务器之间的交互都应实现无状态化。服务器不会存储客户端最近发出的HTTP请求的任何信息。它会将每个请求都视为新请求。没有会话，也没有历史记录。
如果客户端应用程序对于最终用户而言需要是有状态的应用程序，即用户登录一次后可以进行其他授权操作，那么客户端的每个请求都应包含处理该请求所需的所有信息，包括身份验证和授权详细信息。
在请求之间，服务器上不应存储任何客户端上下文。客户端负责管理应用程序的状态。
- 可缓存
在当今世界，只要数据和响应的缓存适用/可能，它们就至关重要。您正在阅读的网页也是HTML页面的缓存版本。缓存能提升客户端的性能，并因负载减少而扩大服务器的可扩展性范围。
在REST中，应在适用的情况下对资源应用缓存，然后这些资源必须声明自己可缓存。缓存可以在服务器端或客户端实现。
管理良好的缓存可以部分或完全消除某些客户端与服务器之间的交互，从而进一步提高可扩展性和性能。
-
分层系统
REST允许您使用分层系统架构，例如，您可以在服务器A上部署API，在服务器B上存储数据，在服务器C中对请求进行身份验证。客户端通常无法判断它是直接连接到最终服务器还是中途的中介服务器。 -
按需编码（可选）
这个约束是可选的。大多数情况下，你会以XML或JSON的形式发送资源的静态表示。但当你需要时，你可以自由地返回可执行代码来支持应用程序的一部分，例如，客户端可能会调用你的API来获取UI小部件的渲染代码。这是允许的。
以上所有约束条件都有助于你构建一个真正的RESTful API，你应该遵循它们。不过，有时你可能会发现自己违反了一两条约束。别担心；你仍然在构建一个RESTful API——只是不是“真正的RESTful”