REST api必须是超文本驱动的

Roy Fielding的博客中有一组方法来检查你正在构建的是HTTP API还是REST API:

API designers, please note the following rules before calling your creation a REST API: A REST API should not be dependent on any single communication protocol, though its successful mapping to a given protocol may be dependent on the availability of metadata, choice of methods, etc. In general, any protocol element that uses a URI for identification must allow any URI scheme to be used for the sake of that identification. [Failure here implies that identification is not separated from interaction.] A REST API should not contain any changes to the communication protocols aside from filling-out or fixing the details of underspecified bits of standard protocols, such as HTTP’s PATCH method or Link header field. Workarounds for broken implementations (such as those browsers stupid enough to believe that HTML defines HTTP’s method set) should be defined separately, or at least in appendices, with an expectation that the workaround will eventually be obsolete. [Failure here implies that the resource interfaces are object-specific, not generic.] A REST API should spend almost all of its descriptive effort in defining the media type(s) used for representing resources and driving application state, or in defining extended relation names and/or hypertext-enabled mark-up for existing standard media types. Any effort spent describing what methods to use on what URIs of interest should be entirely defined within the scope of the processing rules for a media type (and, in most cases, already defined by existing media types). [Failure here implies that out-of-band information is driving interaction instead of hypertext.] A REST API must not define fixed resource names or hierarchies (an obvious coupling of client and server). Servers must have the freedom to control their own namespace. Instead, allow servers to instruct clients on how to construct appropriate URIs, such as is done in HTML forms and URI templates, by defining those instructions within media types and link relations. [Failure here implies that clients are assuming a resource structure due to out-of band information, such as a domain-specific standard, which is the data-oriented equivalent to RPC’s functional coupling]. A REST API should never have “typed” resources that are significant to the client. Specification authors may use resource types for describing server implementation behind the interface, but those types must be irrelevant and invisible to the client. The only types that are significant to a client are the current representation’s media type and standardized relation names. [ditto] A REST API should be entered with no prior knowledge beyond the initial URI (bookmark) and set of standardized media types that are appropriate for the intended audience (i.e., expected to be understood by any client that might use the API). From that point on, all application state transitions must be driven by client selection of server-provided choices that are present in the received representations or implied by the user’s manipulation of those representations. The transitions may be determined (or limited by) the client’s knowledge of media types and resource communication mechanisms, both of which may be improved on-the-fly (e.g., code-on-demand). [Failure here implies that out-of-band information is driving interaction instead of hypertext.]

REST是SOAP的轻版本，不添加糖或着色剂。 SOAP和REST的目标都是允许用不同语言编写并使用不同通信协议的信息系统之间进行通信。

SOAP使用API契约来公开它的服务，并定义客户端调用服务的方式，应该发送什么参数以及预期的结果，而REST则不使用API契约，对于客户端来说，要知道存在什么服务以及如何调用它们，应该查看REST API文档(这可以在OpenAPI或Swagger的yml文件中定义)。

其次，SOAP是冗长的，它使用XML发送请求并描述服务、参数和返回的结果。另一方面，REST依赖简单的JSON对象来发送请求和接收结果。JSON易于理解，轻量级，并且在发送请求或接收结果时不会占用太多带宽。

REST api必须是超文本驱动的

Roy Fielding的博客中有一组方法来检查你正在构建的是HTTP API还是REST API:

API designers, please note the following rules before calling your creation a REST API: A REST API should not be dependent on any single communication protocol, though its successful mapping to a given protocol may be dependent on the availability of metadata, choice of methods, etc. In general, any protocol element that uses a URI for identification must allow any URI scheme to be used for the sake of that identification. [Failure here implies that identification is not separated from interaction.] A REST API should not contain any changes to the communication protocols aside from filling-out or fixing the details of underspecified bits of standard protocols, such as HTTP’s PATCH method or Link header field. Workarounds for broken implementations (such as those browsers stupid enough to believe that HTML defines HTTP’s method set) should be defined separately, or at least in appendices, with an expectation that the workaround will eventually be obsolete. [Failure here implies that the resource interfaces are object-specific, not generic.] A REST API should spend almost all of its descriptive effort in defining the media type(s) used for representing resources and driving application state, or in defining extended relation names and/or hypertext-enabled mark-up for existing standard media types. Any effort spent describing what methods to use on what URIs of interest should be entirely defined within the scope of the processing rules for a media type (and, in most cases, already defined by existing media types). [Failure here implies that out-of-band information is driving interaction instead of hypertext.] A REST API must not define fixed resource names or hierarchies (an obvious coupling of client and server). Servers must have the freedom to control their own namespace. Instead, allow servers to instruct clients on how to construct appropriate URIs, such as is done in HTML forms and URI templates, by defining those instructions within media types and link relations. [Failure here implies that clients are assuming a resource structure due to out-of band information, such as a domain-specific standard, which is the data-oriented equivalent to RPC’s functional coupling]. A REST API should never have “typed” resources that are significant to the client. Specification authors may use resource types for describing server implementation behind the interface, but those types must be irrelevant and invisible to the client. The only types that are significant to a client are the current representation’s media type and standardized relation names. [ditto] A REST API should be entered with no prior knowledge beyond the initial URI (bookmark) and set of standardized media types that are appropriate for the intended audience (i.e., expected to be understood by any client that might use the API). From that point on, all application state transitions must be driven by client selection of server-provided choices that are present in the received representations or implied by the user’s manipulation of those representations. The transitions may be determined (or limited by) the client’s knowledge of media types and resource communication mechanisms, both of which may be improved on-the-fly (e.g., code-on-demand). [Failure here implies that out-of-band information is driving interaction instead of hypertext.]

REST不一定绑定到HTTP。基于rest的web服务只是遵循基于rest的体系结构的web服务。

What is Rest -
1- Client-server
2- Stateless
3- Cacheable
4- Layered system
5- Code on demand
6- Uniform interface

HTTP是一种应用协议。REST是一组规则，遵循这些规则，您就可以构建具有特定约束集的分布式应用程序。

如果您正在寻找REST中区分RESTful应用程序与任何HTTP应用程序的最重要的约束，我会说“自描述”约束和超媒体约束(又名hypermedia as the Engine of application State (HATEOAS))是最重要的。

自描述约束要求RESTful请求在用户意图中是完全自描述的。这允许中介(代理和缓存)安全地对消息进行操作。

HATEOAS约束是关于将您的应用程序转换为一个链接网络，其中客户端的当前状态基于它在该网络中的位置。这是一个棘手的概念，需要比现在更多的时间来解释。

HTTP是一种用于通信的协议，通常用于与互联网资源或web浏览器客户端的任何应用程序通信。

REST意味着您在设计应用程序时使用的主要概念是资源:对于您想要执行的每个操作，您需要定义一个资源，您通常只在该资源上执行CRUD操作，这是一个简单的任务。为此，使用HTTP协议中使用的四个动词来对抗四个CRUD操作非常方便(GET用于读取，POST用于创建，PUT用于更新，DELETE用于删除)。

这与RPC(远程过程调用)的旧概念不同，在RPC中，作为用户调用的结果，您有一组希望执行的操作。例如，如果你考虑如何在一个帖子上描述一个Facebook点赞，使用RPC，你可能会创建名为AddLikeToPost和RemoveLikeFromPost的服务，并管理它与所有与Facebook帖子相关的其他服务，因此你不需要为点赞创建特殊对象。

使用REST，您将拥有一个Like对象，它将与Delete和Create函数分开管理。这也意味着它将在数据库中描述一个单独的实体。这看起来可能是一个很小的差异，但这样工作通常会产生更简单的代码和更简单的应用程序。通过这种设计，应用程序的大部分逻辑从对象的结构(模型)中是显而易见的，不像RPC，你通常必须显式地添加更多的逻辑。

设计RESTful应用程序通常要困难得多，因为它要求您以简单的方式描述复杂的事情。仅使用CRUD函数描述所有功能是很棘手的，但这样做之后，您的生活将简单得多，并且您将发现您编写的方法更短。

One more restraint REST architecture presents is not to use a session context when communicating with a client (stateless), meaning all the information needed to understand who is the client and what he wants is passed with the web message. Each call to a function is self-descriptive, there is no previous conversation with the client which can be referenced in the message. Therefore, a client could not tell you "give me the next page" since you don't have a session to store what is the previous page and what kind of page you want, the client would have to say "my name is Yuval, get me page 2 of a specific post in a specific forum". This means a bit more data would have to transfer in the communication, but think of the difference between finding a bug reported from the "get me the next page" function in oppose to "get me page 2 of question ID 2190836 in stack overflow".

当然还有很多，但在我看来，这些是茶匙的主要概念。