REST API概念

如何解决REST API概念

我正在尝试理解REST API的本质，如果有人可以澄清我有一些疑问，我将很高兴：

第一
摘自Wikipedia：

它是一个Web资源网络（虚拟状态机），用户在其中通过选择诸如http://www.example.com/articles/21之类的资源标识符和诸如GET或POST之类的资源操作（应用程序状态转换）来浏览应用程序，在下一个资源的表示形式（下一个应用程序状态）中转移给最终用户以供使用。

“应用程序状态”是什么意思？据我了解，公开REST API的应用程序是无状态的，因此按定义它没有“状态”吗？它只是回复客户端请求，其中包含服务器响应这些请求所需的所有信息。换句话说，它不包含任何上下文。我说得对吗？

第二
六个约束之一是 client-server 架构。为什么会有约束？每个API都在客户端-服务器体系结构中是不是正确？最终，API是应用程序编程接口。 ??

第三

from here：

使用通用媒体类型（例如JSON）根本不是RESTful的，因为REST要求消息是自描述的。自我描述性只是意味着数据的语义应该与数据本身一起传播。

自我描述性约束的本义是什么？使用通用媒体类型是否违反了该约束？

第四
我已经在很多地方看到REST不是HTTP，并且不必使用HTTP，因为它是令人讨厌的协议，使用HTTP是很自然的，因为它具有一组方法（GET，POST，PUT，DELETE）。有人可以解释为什么REST自然吗，并举例说明使用HTTP以外的REST的另一种方式吗？

解决方法

据我了解，公开REST API的应用程序是无状态的，因此按定义它没有“状态”吗？

否，通信本身应该是无状态的。 REST是代表性状态转移的缩写，因此状态一词甚至包含在名称本身中。

就传统的Web页面而言，可能更容易想到这里。如果您有一台保持客户端状态的服务器（即管理多个客户端会话），那么您迟早会遇到扩展问题。您无法添加客户端可以连接到的其他服务器来检索与会话潮汐之前到达其之前通信的服务器相同的信息。人们可能会尝试通过远程总线（即Redis队列等）共享服务器状态，但这会带来很多其他难题，这些难题很难解决。

用菲尔丁的话来说：

REST是数十年规模的软件设计：每个细节都旨在促进软件的寿命和独立发展。许多约束与短期效率直接相反。不幸的是，人们擅长短期设计，而通常不擅长长期设计。大多数人认为他们不需要在当前版本之后进行设计。 （Source）

在我看来，无状态对独立演进的约束比对系统可伸缩性的约束要小。如果仅基于内容类型协商，HATEOAS的使用等考虑客户端-服务器的解耦，这里的无状态并不是真正的阻止者，尽管如果避免共享客户端状态会占用很多背景复杂性，即整个服务器环境中的当前会话数据。

6个约束之一是客户端-服务器体系结构。为什么会有约束？每个API都在客户端-服务器体系结构中是不是正确？最终，API是应用程序编程接口。 ??

与客户端-服务器体系结构相对应的是什么？不必与其他应用程序打交道的应用程序。如果一个应用程序不必与其他应用程序进行通信，那么您在设计时就不必太小心，因为它必须适应更改或避免其组件之间的任何耦合，因为它始终被视为一回事。如上所述， REST是数十年规模的软件设计。因此，您在网上发布的相同服务仍将在未来几年内发挥作用，并且本质上应该具有未来发展的自由。

互操作性是客户端-服务器体系结构中的核心问题之一。如果两个参与者讲的语言不同或对领域的理解不同，他们将很难相互交流。只需将中国人和法国人放在同一个房间里，看着他们设法解决特定问题即可。除非他们不懂英语这样的最少语言，否则沟通将是解决该问题的主要问题。

自我描述性约束的本义是什么？使用通用媒体类型是否违反了该约束？

首先，我从一篇不错的博客文章中引用此声明：

自我描述性消息是包含收件人理解该消息所需的所有信息的消息。单独的文档或其他消息中不应包含其他信息。 （Source）

如果您现在仔细看一下JSON spec，它仅定义基本语法，而没有定义任何语义。因此，从本质上讲，您知道对象以花括号（{和}开头和结尾，对象由一组键和值组成，其中键是字符串值，并且该值可以可以是字符串，数字，布尔值，另一个对象或数组等。但是它并没有告诉您有关实际结构的任何信息，文件中包含哪些元素等等。 XML，即具有文档类型定义（DTD）和XML模式，它们定义哪些元素和属性按什么顺序排列以及它们的允许值是什么等等。尽管JSON (Hyper-)Schema试图填补这一空白，但它仍未完全定义字段的语义，即在哪些上下文中可能出现哪些元素而什么不出现。 JSON本身也缺乏对URL / URI的支持，并且JSON超模式现在尝试至少增加对它的支持。

如果您查看HTML，即该规范现已通过不同版本，但考虑到向后兼容性，即使在版本5中，您也可以使用原始版本中定义的标记，浏览器将能够或多或少正确地处理您的网页。自我描述的另一部分来自HTML的form support。因此，服务器不仅可以教导客户有关资源的数据元素的信息，即关于希望输入文本的字段名称的信息，而时间字段会为您提供一个日历小部件以选择特定的日期和时间输入等，但是它也可以告诉客户端将请求发送到的URI，使用哪个HTTP操作以及使用哪种媒体类型发送请求。尽管这已经解决了HATEOAS，但了解HTML的客户端将知道服务器希望服务器执行什么操作这样做，因此不需要查阅描述请求外观的任何外部文档。

HTML本质上是一种通用媒体类型。您可以使用它来描绘特定汽车模型的细节，也可以显示新闻和其他数据。最后，媒体类型仅是人类可读的定义，即应用程序（客户端或服务器）应如何处理据说具有该格式的数据。因此，通用媒体类型优于特定媒体类型，因为它允许并促进该媒体类型在许多其他域中的重用，并且增加了跨不同供应商支持该媒体类型的可能性。

我已经在很多地方看到REST不是HTTP，并且因为它是令人讨厌的协议而不必使用HTTP，所以使用HTTP是很自然的，因为它具有一组方法（GET，POST，PUT，DELETE） ）。有人可以解释为什么REST自然吗，并举例说明使用REST而非HTTP的另一种方式吗？

正如“鲍勃叔叔”马丁所说的architecture is about intent。如前所述，REST就是将客户端与服务器分离，以使服务器在将来自由发展，并使客户端能够轻松地适应变化。就是说，基本上可以使Web增长到今天的大小。菲尔丁只接受了在Web上成功使用的概念，这些概念大多数是人类使用的，并且开始质疑为什么应用程序也没有使用我们与Web交互的风格。因此，从广义上讲，REST只是针对应用程序的Web冲浪。

REST本身只是一种建筑风格。就像有些教堂使用哥特式风格，有些教堂采用现代风格，而另一些采用巴洛克风格一样，每种风格都有其独特的特性，与众不同。在软件工程中，您还可以遵循几种不同的样式，例如单片或n层体系结构，MVC体系结构，领域特定语言（DSL），SOA，对等体系结构，云计算（无服务器，.. 。） 等等。这些中的每一个都有自己的特征和独特的主张特征，优缺点。与传统架构一样，您可以将不同的样式混合并匹配为一种方法，尽管最终结果可能并非您最初打算并记住的，每种样式都试图解决至少一个主要问题。

Fielding正在研究HTTP 1.0和1.1规范（以及其他规范），并在此博士论文中分析了Web的体系结构。因此，在我看来，REST在HTTP之上运行良好并不是什么奇迹，但是正如已经提到的那样，他可能已经仔细研究了HTTP和Web，因为至少从我的理解来看，无状态是一个较少的问题。未来的发展而不是可扩展性。尽管可伸缩性也可能会成为未来的关注点，但是即使Fielding声称所有约束对于保留REST标签都是必不可少的，但在这方面，我也不会将其称为高优先级约束。

因此，REST本身并没有将您绑定到HTTP，因为它只是一种体系结构样式。它并不禁止偏离其核心思想，但是您可能会错过它所倡导的某些属性（最终会误用REST）。但是，由于REST与HTTP几乎并驾齐驱，就像是完美匹配，为什么要更改它？当然，您将来可能会提出一个新的传输协议，并将用于与Web页面进行交互的相同概念应用于该协议，并且您或多或少都会采用REST体系结构。但是，您的协议至少应支持URI，媒体类型，链接关系和content-type negotiation。这些是每个启用REST的应用程序都需要支持的IMO的基本模块，因为这些模块保证了定义明确的消息的交换以及对这些消息采取行动的能力。

就像HTTP is just a transport protocol一样，将文档从源计算机传输到目标计算机时，人们可能会质疑为什么REST体系结构也没有使用SMTP，FTP或类似协议。尽管这些协议也将文档从一个点传送到另一点，但它们要么不支持媒体类型（S / FTP / S），要么不完全支持统一接口约束，即不完全支持HATEOAS等。除此之外，两者都需要特定的登录名才能创建会话，这可能会或不会被视为违反无状态约束。