甲协议通常描述的确切的消息(或其部分)的两个(或多个)对等体必须交换.同时指定编排如何交换这些消息及其含义.
一种建筑风格(如REST)不会在所有描述的消息,但指定的要求(体系结构约束)的消息,编排或部分系统必须满足.
因此,虽然协议可能会说:"使用以下格式的JSON来请求引用".一种建筑风格只是说:"客户可以联系服务器,但不是其他方式".这是一个完全不同的水平.
以下是它们的相关性:架构风格就像是特定架构的模板.特定体系结构反过来定义组件之间的协议.
我读到 Rest 是一种架构风格，而不是一种协议。如果有人能详细说明这一点，我将不胜感激。
来自菲尔丁的论文
架构风格是一组协调的架构约束，它限制了架构元素的角色/特征以及在符合该风格的任何架构中这些元素之间允许的关系。
构成 REST 架构风格的架构约束的概述在5.1 节中描述
回顾 Fielding在 AEM 中的演示文稿REST也可能有所帮助，他指出了对 REST 是什么的具体误解。
超文本传输协议 (HTTP) 是一种无状态的应用程序级请求/响应协议，它使用可扩展语义和自描述消息有效载荷与基于网络的超文本信息系统进行灵活交互。
您可以查看 Jan Newmarch 的Network Programming in Go，其中有一章关于应用程序级协议。
协议通过指定消息、数据类型、编码格式等来定义分布式应用程序的两个组件之间可以发生什么类型的对话。
您会注意到，REST 没有指定其中任何一项——它只限制您可以做出的选择。
一个很好的类比是将协议视为如何编写消息，将 REST 视为机器如何处理它接收到的消息。
将协议视为定义如何组织两个端点之间的数据。有喜欢的几种不同的协议HTTP，TCP，IP和ARP。它们的共同点是，它们代表了如何以通用方式定义数据的标准，以便任何运行可以通过这些协议解释数据的程序的机器都将正确、准确地解释信号。在每种情况下，每次您发出请求时，您都会将二进制文件发送到网络（可以包括互联网）。二进制表示的配置方式是，它们是在协议中配置的消息，例如HTTP取决于您关注的网络层的哪一层（HTTP位于应用程序层，您可以在此处阅读更多信息：OSI 模型）。
另一方面，REST 仅在其消息被解释后处理发送到端点的数据。换句话说，接收到一条消息，将该消息转换为命令，执行这些命令，生成响应，并且使用协议（通常HTTP在应用层中）转换该响应消息，然后将其作为响应发回。
当 A 点向 B 点的 REST API 架构发送请求时，它首先将该数据转换为标准化协议（例如HTTP，application layer根据需要在其他地方），然后通过网络发送该消息，直到到达 B 点。当 B 点收到该消息时data 它转换该数据并将其传递到其 REST API，该 API 将数据解释为命令并运行其特定功能。API 擦写的功能完成后，它使用协议再次对数据进行编码，并将响应发送回 A 点。
你可以这样想。该协议创建消息，以便它可以被发送和理解。REST 负责确保服务器执行预期的操作，而不是定义如何组织数据的标准，以便所有可能的端点都能识别它。
这里有一些很好的参考：
这很复杂，需要一段时间才能掌握。除了我在此处展示的内容之外，还有更多内容，但希望它可以为您提供一个良好的起点。
| 归档时间： |
|
| 查看次数： |
4495 次 |
| 最近记录： |