REST代表Representational State Transfer，这是Roy Fielding在2000年创造的一个术语。它是一种通过HTTP设计松散耦合应用程序的架构风格，通常用于Web服务的开发。REST没有强制执行任何有关如何在较低级别实现它的规则，它只是提出了高级设计指南，让您考虑自己的实现。
在我上一次工作中，我为电信大公司设计了RESTful API已有2年了。在这篇文章中，我将分享我的想法，除了正常的设计实践。你可能不同意我的几点，这是完全可以的。我很乐意以开放的心态与您讨论任何事情。
让我们从标准设计特定的东西开始，以清除'Roy Fielding'希望我们构建的内容。然后我们将讨论我在设计RESTful API时更加注重细节的东西。
REST定义了6个架构约束，它们构成了任何Web服务 - 一个真正的RESTful API。
由于约束名称本身适用，您必须为系统内部的资源决定API接口，这些资源暴露给API消费者并且遵循宗教信仰。系统中的资源应该只有一个逻辑URI，并且应该提供获取相关或附加数据的方法。将资源与网页同步化总是更好。
任何单个资源都不应该太大，并且在其表示中包含每个和所有内容。只要相关，资源应包含指向相对URI的链接（HATEOAS）以获取相关信息。
此外，跨系统的资源表示应遵循某些指导原则，如命名约定，链接格式或数据格式（xml或/和json）。
所有资源都应该通过HTTP GET等通用方法访问，并使用一致的方法进行类似修改。
一旦开发人员熟悉了您的某个API，他就应该能够对其他API采用类似的方法。
这实质上意味着客户端应用程序和服务器应用程序必须能够单独进化而不相互依赖。客户端应该只知道资源URI，这就是全部。今天，这是Web开发中的常规做法，因此您无需花费任何精力。把事情简单化。
服务器和客户端也可以独立替换和开发，只要它们之间的接口不被改变即可。
Roy fielding从HTTP获得灵感，因此它反映了这种约束。使所有客户端 - 服务器交互无状态。服务器不会存储有关最新HTTP请求客户端的任何内容。它会将每个请求视为新的。没有会话，没有历史。
如果客户端应用程序需要是最终用户的有状态应用程序，用户登录一次并在此后执行其他授权操作，则客户端的每个请求都应包含服务请求所需的所有信息 - 包括身份验证和授权详细信息。
请求之间不应在服务器上存储客户端上下文。客户端负责管理应用程序的状态。
在当今世界，数据和响应的缓存在任何适用/可能的地方都至关重要。您在此处阅读的网页也是HTML页面的缓存版本。缓存为客户端带来性能改进，并为服务器提供更好的可扩展性范围，因为负载已经减少。
在REST中，缓存应在适用时应用于资源，然后这些资源必须声明自己可缓存。缓存可以在服务器或客户端实现。
管理良好的缓存部分或完全消除了一些客户端 - 服务器交互，进一步提高了可伸缩性和性能。
REST允许您使用分层系统体系结构，在服务器A上部署API，并在服务器B上存储数据，并在服务器C中验证请求。客户端通常无法判断它是直接连接到终端服务器，还是沿途的中介。
好吧，这个约束是可选的。大多数情况下，您将以XML或JSON的形式发送资源的静态表示。但是当您需要时，您可以自由地return executable code支持您的应用程序的一部分，例如客户可以调用您的API来获取UI小部件呈现代码。这是允许的。
以上所有限制都有助于您构建真正的RESTful API，您应该遵循它们。尽管如此，有时您可能会发现自己违反了一两个限制因素。别担心，你仍在制作一个RESTful API - 但不是“真正的RESTful”。
请注意，上述所有约束都与WWW（Web）密切相关。使用RESTful API，您可以对Web服务执行与Web页面相同的操作。
Powered by RESTful API 中文网 + with by 全栈开发网. 网站地图 按Ctrl+D试试 .