REST API的设计风格是什么样的，很多新手对此不是很清楚，为了帮助大家解决这个难题，下面小编将为大家详细讲解，有这方面需求的人可以来学习下，希望你能有所收获。
有些人可能会强烈反对上面提到的/translate和其他JSON路由是API路由。其他人可能会同意，但也会认为它们是一个设计糟糕的API。那么一个精心设计的API有什么特点，为什么上面的JSON路由不是一个好的API路由呢？
你可能听说过RESTAPI。REST（RepresentationalStateTransfer）是RoyFielding在博士论文中提出的一种架构。该架构中，Dr.Fielding以相当抽象和通用的方式展示了REST的六个定义特征。
除了Dr.Fielding的论文外，没有关于REST的权威性规范，从而留下了许多细节供读者解读。一个给定的API是否符合REST规范的话题往往是REST“纯粹主义者”之间激烈争论的源头，REST“纯粹主义者”认为RESTAPI必须以非常明确的方式遵循全部六个特征，而不像REST“实用主义者”那样，仅仅将Dr.Fielding在论文中提出的想法作为指导原则或建议。Dr.Fielding站在纯粹主义阵营的一边，并在博客文章和在线评论中的撰写了一些额外的见解来表达他的愿景。
目前实施的绝大多数API都遵循“实用主义”的REST实现。包括来自Facebook，GitHub，Twitter等“大玩家”的大部分API都是如此。很少有公共API被一致认为是纯REST，因为大多数API都没有包含纯粹主义者认为必须实现的某些细节。尽管Dr.Fielding和其他REST纯粹主义者对评判一个API是否是RESTAPI有严格的规定，但软件行业在实际运用中引用REST是很常见的。
无状态原则是REST纯粹主义者和实用主义者之间争论最多的两个中心之一。它指出，RESTAPI不应保存客户端发送请求时的任何状态。这意味着，在Web开发中常见的机制都不能在用户浏览应用程序页面时“记住”用户。在无状态API中，每个请求都需要包含服务器需要识别和验证客户端并执行请求的信息。这也意味着服务器无法在数据库或其他存储形式中存储与客户端连接有关的任何数据。
如果你想知道为什么REST需要无状态服务器，主要原因是无状态服务器非常容易扩展，你只需在负载均衡器后面运行多个服务器实例即可。如果服务器存储客户端状态，则事情会变得更复杂，因为你必须弄清楚多个服务器如何访问和更新该状态，或者确保给定客户端始终由同一服务器处理，这样的机制通常称为粘性会话。
再思考一下本章介绍中讨论的/translate路由，就会发现它不能被视为RESTful，因为与该路由相关的视图函数依赖于Flask-Login的@login_required装饰器，这会将用户的登录状态存储在Flask用户会话中。
客户端－服务器原则相当简单，正如其字面含义，在RESTAPI中，客户端和服务器的角色应该明确区分。在实践中，这意味着客户端和服务器都是单独的进程，并在大多数情况下，使用基于TCP网络上的HTTP协议进行通信。
分层系统原则是说当客户端需要与服务器通信时，它可能最终连接到代理服务器而不是实际的服务器。因此，对于客户端来说，如果不直接连接到服务器，它发送请求的方式应该没有什么区别，事实上，它甚至可能不知道它是否连接到目标服务器。同样，这个原则规定服务器兼容直接接收来自代理服务器的请求，所以它绝不能假设连接的另一端一定是客户端。
这是REST的一个重要特性，因为能够添加中间节点的这个特性，允许应用程序架构师使用负载均衡器，缓存，代理服务器等来设计满足大量请求的大型复杂网络。
看完上述内容是否对您有帮助呢？如果还想对相关知识有进一步的了解或阅读更多相关文章，请关注创新互联行业资讯频道，感谢您对创新互联网站建设公司，的支持。
重庆分公司
重庆分公司
