REST或RESTful API设计（代表性状态转移）旨在利用现有协议。尽管REST几乎可以在任何协议上使用，但是当用于Web API时，通常会利用HTTP。这意味着开发人员无需安装库或其他软件即可利用REST API设计。REST API设计由Roy Fielding博士在其2000年的博士学位论文中定义。它以其令人难以置信的灵活性而著称。由于数据不依赖于方法和资源，因此REST能够处理多种类型的调用，返回不同的数据格式，甚至可以通过正确实施超媒体来进行结构更改。 
REST API设计固有的自由度和灵活性使您可以构建既能满足您的需求又能满足非常多样化的客户需求的API。与SOAP不同，REST并不限于XML，而是可以返回XML，JSON，YAML或任何其他格式，具体取决于客户端的请求。而且与RPC不同，不需要用户按特定顺序知道过程名称或特定参数。 但是，REST API设计存在一些缺点。您可能会失去在REST中（例如在会话中）维护状态的能力，并且较新的开发人员更难以使用。在构建API之前，了解使REST API成为RESTful的原因以及为什么存在这些约束也很重要。毕竟，如果您不了解为什么要按某种方式设计某件东西，那么您可能会阻碍自己的努力，甚至没有意识到。
了解REST API设计
尽管大多数API声称是RESTful的，但它们未达到Fielding博士所主张的要求和约束。在确定这是否是您的项目的正确API类型时，需要注意REST API设计的六个主要限制。
客户端服务器
客户端-服务器约束基于这样的概念：客户端和服务器应彼此分离，并可以独立且独立地发展。换句话说，我应该能够对移动应用程序进行更改，而不会影响服务器上的数据结构或数据库设计。同时，我应该能够修改数据库或对服务器应用程序进行更改，而不会影响移动客户端。这就造成了关注点的分离，使每个应用程序都可以独立于其他应用程序进行扩展和扩展，并允许您的组织快速高效地进行扩展。
无状态
REST API是无状态的，这意味着调用可以彼此独立进行，并且每个调用都包含成功完成自身所需的所有数据。REST API不应依赖存储在服务器或会话中的数据来确定如何处理调用，而应仅依赖于该调用本身中提供的数据。进行呼叫时，标识信息未存储在服务器上。相反，每个调用本身都具有必要的数据，例如API密钥，访问令牌，用户ID等。这也通过拥有进行调用所需的所有数据，而不是依赖一系列来帮助提高API的可靠性。具有服务器状态的调用创建对象，这可能会导致部分失败。相反，为了减少内存需求并保持您的应用程序尽可能可扩展，
快速
由于无状态API会通过处理大量传入和传出调用而增加请求开销，因此REST API应该设计为鼓励存储可缓存数据。这意味着，当数据是可缓存的时，响应应指示该数据可以存储到一定时间（到期时间），或者在数据需要实时的情况下，响应不应该被缓存。客户。通过启用此关键约束，您不仅可以大大减少与API的交互次数，减少内部服务器的使用，还可以为您的API用户提供必要的工具，以提供最快，最高效的应用程序。请记住，缓存是在客户端完成的。虽然您可以在架构中缓存一些数据以执行整体性能，
统一界面
客户端与服务器解耦的关键是具有统一的接口，该接口允许应用程序独立发展，而无需将应用程序的服务，模型或操作紧密耦合到API层本身。统一的界面使客户端可以使用单一语言与服务器进行通信，而与任一服务器的体系结构后端无关。该接口应该提供一种不变的，标准化的客户端与服务器之间的通信方式，例如将HTTP与URI资源，CRUD（创建，读取，更新，删除）和JSON一起使用。
分层系统
顾名思义，分层系统是由层组成的系统，每个层都有特定的功能和职责。如果我们想到一个Model View Controller框架，则每一层都有其自己的职责，其中的模型包括应如何形成数据，控制器专注于传入动作以及视图专注于输出。每一层是独立的，但也相互影响。在REST API设计中，相同的原则仍然适用，架构的不同层协同工作以构建有助于创建更具可扩展性和模块化的应用程序的层次结构。 分层系统还使您可以封装遗留系统，并将较少访问的功能移至共享的中介，同时还可以从中屏蔽更现代和常用的组件。此外，分层系统使您可以随技术和服务的发展而自由地将系统移入或移出体系结构，只要您保持不同模块之间的松散耦合，就可以提高灵活性和使用寿命。有大量的安全保障具有分层系统，因为它可以阻止代理层或其他层的攻击，从而阻止攻击进入您的实际服务器体系结构。通过将分层系统与代理一起使用，或创建单个访问点，您可以将体系结构的关键和更易受攻击的方面保留在防火墙之后，从而防止客户端直接与它们进行交互。请记住，安全性不是基于单一的“全部停止”解决方案，而是基于多层，并且要了解某些安全性检查可能会失败或被绕过。这样，您可以在系统中实现的安全性越高，就越有可能防止破坏性攻击。
按需编码
按需编码可能是六个约束中鲜为人知的，也是唯一可选的约束，它允许通过API传输代码或小应用程序以在应用程序中使用。从本质上讲，它创建了一个智能应用程序，该应用程序不再完全依赖于自己的代码结构。但是，也许因为它已经超前了，所以按需编码一直在努力采用，因为Web API被跨多种语言使用，并且代码的传输引起了安全性问题和关注。（例如，该目录必须是可写的，并且防火墙必须让通常受限制的内容通过。） 这些约束共同构成了代表性状态转移或REST的理论。当您回顾这些内容时，您会看到每个连续的约束是如何在先前约束的基础上构建的，最终创建了一个相当复杂但功能强大且灵活的应用程序接口。但最重要的是，这些限制构成了一种设计，其运作方式与我们在万维网上的浏览器中访问页面的方式类似。它创建的API不是由其体系结构决定的，而是由它返回的表示形式决定的，并且创建一个API（虽然在架构上是无状态的），但该表示形式决定了应用程序的状态。
本文采用 署名-非商业性使用-相同方式共享 4.0 国际 许可协议，转载请注明出处。
