这是一个小细节（也可能是宗教）问题。让我们假设我们正在构建一个REST架构，为了明确，我们假设服务需要三个参数， x ， y 和 z 。阅读有关REST的各种工作，似乎应该将其表示为类似
的URIhttp://myservice.example.com/service/ x / y / z
过去写过很多CGI，表达这个似乎很自然
是否有任何特别的理由喜欢全斜线形式？
答案 0 :(得分：10)
原因很小但是现在是。
酷URI不要改变。
http://myservice.example.com/resource/x/y/z/形式在上帝面前声称，并且每个人都认为这是特定资源的路径。
请注意，我更改了名称。可能涉及服务，但REST原则是您描述了一个名为
/x/y/z/的特定Web资源。
http://myservice.example.com/service?x=val,y=val,z=val表单并没有那么强烈。它说有一段名为service的代码会尝试进行某种查询。没有保证。
答案 1 :(得分：4)
查询参数很少“酷”。看看Google Chart API。是否应对所有字段使用/ full / path /表示法？如果确实如此，每个网址都会很酷吗？
查询参数很有用。可以省略可选字段。可以添加新密钥以支持新功能。随着时间的推移，可以弃用和删除旧字段。使用/ path / notation这样做很笨拙。
引自http://www.xml.com/pub/a/2004/08/11/rest.html
URI不透明度[BP]
URI的创建者决定编码 的URI，用户不应该派生 来自URI本身的元数据。 URI不透明度 仅适用于URI的路径。该 查询字符串和片段有特殊之处 用户可以理解的含义。 必须有一个共享词汇 服务及其消费者。
这听起来像是你想要的查询字符串。
查询字符串的一个缺点是无序。以“？x = 1＆amp; y = 2”结尾的GET与以“？y = 2＆amp; x = 1”结尾的GET不同。这意味着浏览器和任何其他中间系统将无法缓存它，因为缓存是基于完整的URL完成的。如果这是一个问题，那么以明确定义的顺序生成查询字符串。
答案 2 :(得分：2)
构建URI时，这是我遵循的原则。我不知道在所有情况下是否完全可以接受
比方说，我必须获取员工的详细信息，然后URI将采用以下形式：
GET / employees / 1 / 而非 GET / employees？id = 1 因为我将每位员工视为资源而整个URI“员工/ {id}“用于识别资源。
另一方面，如果我的算法操作不能识别特定的资源，但只需要输入算法来反过来识别资源，那么我就会使用查询字符串。
例如GET / employees？empname ='％Bob％'＆amp; maxResults = 100 可能会给我所有姓名中都包含Bob字样的员工，查询返回的最大结果限于100人。
希望这能回答你的问题
答案 3 :(得分：2)
URI严格分为层次结构部分（路径）和非分层路径（查询），均用于标识资源
URI规范本身（RFC 3986）明确地将URI的路径和查询部分设置为相等。
第3.3节：
路径组件包含与[查询]组件一起的数据 用于识别资源。
第3.4节：
查询组件包含与...一起的数据 [...]路径组件用于识别资源
因此，如果x，y或z本质上是分层的，或者如果它们是非分层的，并且如果您能够一直感知它们，那么您在使用x/y/z与x=val&y=val&z=val时的选择主要是这样做的。在可预见的未来是分层的或非等级的，以及您在选择其中一个时可能遇到的任何技术限制。
但要回答你的问题，就像其他人已经注意到的那样：两者都没有比另一个更好，因为他们最终都找到了资源。
答案 4 :(得分：0)
如果资源是服务，与参数无关，则应为
http://myservice.example.com/service?x=val&y=val&z=val
这是一个GET查询。 REST背后的原则之一是你要读取（但不能修改！）资源;你可以POST来修改资源＆amp;得到回应;你可以PUT写一个资源;并且您可以删除以删除资源。
如果具有这些参数的特定资源是持久资源，则需要名称。您可以（如果您以这种方式组织您的Web服务）POST到http://myservice.example.com/service?x=val&y=val&z=val以创建服务的特定实例并让它返回一个ID来命名此实例，例如
http://myservice.example.com/service/12312549
然后使用GET / POST / PUT / DELETE与该实例进行交互。
答案 5 :(得分：0)
首先，将URI定义为API的一部分违反了REST体系结构的约束。你不能这样做并将你的API称为RESTful。
其次，查询参数对非查询资源访问不利的原因是它们通常不被缓存。它也违反了HTTP标准。
答案 6 :(得分：-1)
带有/x/y/z/等斜杠的网址会强加层次结构，并不适合仅传递三个参数的确切情况。
如果像你说的那样，x y z确实只是参数且顺序并不重要，那么使用分号会更加RESTful：
http://myservice.example.com/service/x;y;z/
如果你的“服务”只是一个与不同参数相同的算法，那么使用?x=val格式也不会有任何不满意。