HATEOAS是否暗示查询字符串不是RESTful？
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”。
我建议，除非客户端正在填写参数，否则URI没有任何意义。
这对我来说并不正确。 如果您要求服务器提供一些照片，服务器返回如下内容完全有效：
<photos>
<photo url="http://somewhere/photo?id=1"/>
<photo url="http://somewhere/photo?id=2"/>
</photos>
你可以使用/photo/id/xx路径，但那不是重点。 即使没有客户更改它们，这些URL也是可用的。 至于你的第二点：
如果客户端正在填充参数，那么它会掺杂服务器提供的URI，我想知道这是否违反了RESTful原则。
我想这是你问题的核心。 我不认为你必须将URL作为不透明的标识符，请参阅Roy Fielding自己的这段引用：
REST不要求URI不透明。 在我的论文中，唯一出现不透明词的地方就是我抱怨饼干不透明的地方。 事实上，RESTful应用程序在任何时候都被鼓励使用具有人类意义的分层标识符，以最大限度地简化原始应用程序所期望的信息的使用。
用Roy Fielding自己的话来说（文章中的第四点）：
REST API不能定义固定的资源名称或层次结构（客户端和服务器的明显耦合）。 服务器必须有自由控制自己的命名空间。 相反， 允许服务器通过在媒体类型和链接关系中定义这些指令来指导客户如何构建适当的URI，例如在HTML表单和URI模板中完成 。
换句话说，只要客户端没有得到他们需要在带外信息中生成URI的部分，HATEAOS就不会受到侵犯。
请注意， URI模板也可以在没有查询字符串的URI中使用：
http://example.com/dictionary/{term}
因此，问题更多的是关于是否允许客户端构造URL，而不是使用RESTful来使用查询字符串。
请注意，上述示例中提供给客户端的信息量如何完全等同于提供所有可能术语的详尽列表，但从带宽的角度来看，效率更高。
它还允许客户在尊重HATEAOS的同时搜索字典，这在没有带内指示的情况下是不可能的。 我非常有信心罗伊菲尔丁没有推广没有任何搜索功能的网络......
关于您的第三条评论，我认为Roy Fielding鼓励API设计者在HATEAOS之上将“透明”URI作为额外功能。 在zoul的回答中，我不会将他的引用解释为客户会使用“常识”以明确的URI导航API。 他们仍然会使用带内指令（如表单和URI模板）。 但是，这并不意味着透明URI不会比黑暗，令人惊讶，不透明的URI更好。
实际上，透明的URI为API提供了附加价值（调试是一种用例，我可以想到透明URI在哪里是无价的）。
有关URI模板的更多信息，可以查看RFC6570。
我认为REST本身并没有说明URI是不透明还是透明的，但是REST应用不应该依赖于客户端来构造服务器尚未告知它的URI。 服务器执行此操作的方式有很多种：例如，可能包含指向其成员的链接的集合，或者使用GET方法的HTML表单显然会导致带有参数的URI在客户端创建并获取，或者至少有一些URI模板的建议标准。 对REST来说重要的是，服务器应该在给客户端的响应中以某种方式定义有效URI的描述，而不是在某些带外API文档中
URI透明是一件好事，就像任何地方的透明度都是一件好事一样 - 它促进并允许超出设计者最初想象的资源的新颖和非计划用途 - 但（至少在我的理解中）好的URI并不是必需的将接口描述为RESTful
链接地址: http://www.djcxy.com/p/41013.html