HATEOAS是否暗示查询字符串不是RESTful？

Question

HATEOAS(超媒体作为应用程序状态的引擎)建议是否暗示查询字符串不是RESTful？

编辑:下面建议查询字符串可能与状态无关,因此问题令人费解.我建议除非客户端填充参数,否则URI有一个查询字符串是没有意义的.如果客户端正在填充参数,那么它正在掺杂服务器提供的URI,我想知道这是否违反了RESTful原则.

编辑2:我意识到如果客户端将其视为不透明(查询字符串可能是遗留的,因此方便),查询字符串似乎无害.然而,在下面的一个答案中引用Roy Fielding的话说,URI应该被认为是透明的.如果它是透明的,那么我相信鼓励掺假,这似乎淡化了HATEOAS原则.这种稀释是否仍然与HATEOAS一致？这引发了一个问题,即REST是否需要建立URI构建的紧密耦合.

更新在这个REST教程http://rest.elkstein.org/中,建议URI构建设计不好而且不是RESTful.它还在接受的答案中迭代@zoul所说的内容.

例如,"产品列表"请求可以返回每个产品的ID,并且规范说您应该使用http://www.acme.com/product/PRODUCT_ID来获取其他详细信息.这是糟糕的设计.相反,响应应包括每个项目的实际URL:http://www.acme.com/product/001263等.是的,这意味着输出更大.但这也意味着您可以根据需要轻松地将客户端定向到新的URL

如果一个人正在查看此列表并且不想要他/她可以看到的内容,则可能存在"前10个项目"和"下一个10个项目"按钮,但是,如果没有人,而是客户端程序REST的这个方面似乎有点奇怪,因为客户端程序可能没有用的所有" http:// www ".

Answer 1

罗伊·菲尔丁用自己的话说(文章第4点):

REST API不能定义固定资源名称或层次结构(客户端和服务器的明显耦合).服务器必须能够自由控制自己的命名空间.相反,允许服务器通过在媒体类型和链接关系中定义这些指令来指示客户端如何构造适当的URI,例如在HTML表单和URI模板中完成的.

换句话说,只要客户端没有获得在带外信息中生成URI所需的部分,就不会违反HATEAOS.

请注意, URI模板也可以在没有查询字符串的URI中使用:

http://example.com/dictionary/{term}

所以问题更多的是关于允许客户端构造URL是否是RESTful,而不是使用查询字符串是否是RESTful.

请注意上面示例中为客户端提供的信息量与提供所有可能术语的详尽列表完全等效,但从带宽的角度来看效率要高得多.

它还允许客户端在尊重HATEAOS的同时搜索字典,如果没有带内指令,这将是不可能的.我非常有信心Roy Fielding在没有任何搜索功能的情况下不推广网络......

关于你的第三条评论,我认为Roy Fielding正在鼓励API设计师在HATEAOS之上使用"透明"URI作为额外功能.我没有在zoul的答案中解释他的引用,因为客户会使用"常识"来使用明确的URI来导航API.他们仍然会使用带内指令(如表单和URI模板).但这并不意味着透明URI并不比黑暗,令人惊讶,不透明的URI更好.

实际上,透明URI为API提供了附加值(调试是我能想到的一个用例,它具有透明URI非常宝贵).

有关URI模板的更多信息,您可以查看RFC6570.

Answer 2

我的看法是REST本身没有说明URI是不透明还是透明,但REST应用程序不应该依赖客户端来构造服务器尚未告诉它的URI.服务器有多种方法可以执行此操作:例如,可能包含指向其成员的链接的集合或带有GET方法的HTML表单显然会导致在客户端创建带有params的URI并获取,或者至少有一些建议的URI模板标准.REST的重要之处在于,有效URI的描述应该由服务器在它给客户端的响应中以某种方式定义,而不是在某些带外API文档中定义

URI透明度以同样的方式一件好事,因为透明度的任何地方是一件好事-它促进并允许对资源的小说和非计划的用途超出了设计者最初想象的-但(在我的理解至少)漂亮的URIs不在需要到将接口描述为RESTful

Answer 3

\n

我建议，除非客户端填写参数，否则 URI 具有查询字符串是没有意义的。

\n

\n\n

这对我来说似乎并不正确。如果您向服务器请求一些照片，那么服务器返回如下内容是完全有效的：

\n\n

<photos>\n    <photo url="http://somewhere/photo?id=1"/>\n    <photo url="http://somewhere/photo?id=2"/>\n</photos>\n

\n\n

您可以使用/photo/id/xx路径代替，但 \xe2\x80\x99 不是重点。即使客户端不更改这些 URL，它们也是可用的。至于你的第二点：

\n\n

\n

如果客户端正在填充参数，那么它就掺假了服务器提供的 URI，我想知道这是否违反了 RESTful 原则。

\n

\n\n

我想这就是你问题的核心。我不认为\xe2\x80\x99t 必须将 URL 视为不透明标识符，请参阅Roy Fielding 本人的引用：

\n\n

\n

REST 不要求 URI 不透明。在我的论文中，唯一出现“不透明”一词的地方是我抱怨 cookies 的不透明性。事实上，RESTful 应用程序在任何时候都被鼓励使用人类有意义的分层标识符，以便最大限度地偶然使用超出原始应用程序预期的信息。

\n

\n