关于REST URL的详细问题

Question

这是其中一个小细节(可能是宗教问题)。让我们假设我们正在构建REST体系结构，对于确定性，让我们假设服务需要三个参数，x、y和z。

http://myservice.example.com/service/ x/y/z

在过去写了很多CGI之后，表达这些似乎是很自然的。

http://myservice.example.com/service?x=val,y=val,z=val

有什么特别的理由喜欢全斜杠的形式吗？

Answer 1

原因很小，但就在这里。

酷URI的“不改变”。

http://myservice.example.com/resource/x/y/z/表单在上帝和每个人面前宣称，这是通向特定资源的道路。

注意我改了名字。可能涉及到一个服务，但REST原则是描述一个特定的web资源，名为/x/y/z/。

http://myservice.example.com/service?x=val,y=val,z=val表单没有那么强大的声明。它说，有一段名为service的代码将尝试执行某种查询。没有保证。

Answer 2

查询参数很少“酷”。看一看谷歌图表API。应该对所有字段使用/full/path/表示法吗？如果是的话，每个URL都会很酷吗？

查询参数很有用。可以省略可选字段。可以添加新键以支持新功能。随着时间的推移，旧的字段可以被废弃和删除。使用/path/表示法执行此操作比较笨拙。

引用http://www.xml.com/pub/a/2004/08/11/rest.html

URI不透明度BP URI的创建者决定URI的编码，用户不应该从URI本身派生元数据。URI不透明度只适用于URI的路径。查询字符串和片段具有用户可以理解的特殊含义。服务和它的使用者之间必须有一个共享的词汇表。

这听起来像是您想要的查询字符串。

查询字符串的一个缺点是这些字符串是无序的。以"?x=1&y=2“结尾的GET与以"?y=2&x=1”结尾的GET不同。这意味着浏览器和任何其他中间系统都无法缓存它，因为缓存是基于完整的URL完成的。如果这是一个关注点，那么以一个定义良好的顺序生成查询字符串。

Answer 3

在构建URI时，这是我遵循的原则。我不知道这是否在所有情况下都是完全可以接受的

例如，如果我必须获得员工的详细信息，那么URI将是表单：

GET /employees/1/而不是GET /employees?id=1，因为我将每个员工视为一个资源，并且使用整个URI /employees?id=1来标识资源。

另一方面，如果我的算法操作不能识别特定的资源，而只是需要算法的输入，而该算法又可以识别资源，那么我就使用查询字符串。

例如，GET /employees?empname='%Bob%'&maxResults=100可能会给我所有名字中有Bob字的雇员，查询返回的最大结果限制在100。

希望这能回答你的问题