原因很小，但是在这里。

酷的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的代码片段将尝试进行某种查询。不能保证。

查询参数很少会很“酷”。看看Google Chart API。它是否应该对所有字段使用/full/path/notation？如果每个URL都这样做，那它们是否都很酷呢？

查询参数很有用。可以省略可选字段。可以添加新键来支持新功能。随着时间的推移，旧字段可以被弃用并删除。使用“/路径/符号”做这些操作会比较笨拙。

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

URI不透明度[BP]

The creator of a URI decides the encoding of the URI, and users should not derive metadata from the URI itself. URI opacity only applies to the path of a URI. The query string and fragment have special meaning that can be understood by users. There must be a shared vocabulary between a service and its consumers.

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

查询字符串的一个缺点是它们是无序的。以"?x=1&y=2" 结尾的 GET 请求与以"?y=2&x=1" 结尾的请求不同。这意味着浏览器和其他中间系统无法缓存它，因为缓存是基于完整的 URL 进行的。如果这是一个问题，那么请按照明确定义的顺序生成查询字符串。

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

例如，假设我必须获取员工的详细信息，那么URI的形式将是：

使用GET /employees/1/而不是GET /employees?id=1，因为我把每个员工都视为资源，整个URI "employees/{id}"用于标识资源。

另一方面，如果我的算法操作不将特定资源标识为资源，而只需要输入算法，这些输入又识别资源，则我使用查询字符串。

例如 GET /employees?empname= %Bob% &maxResults=100 可能会向我提供所有名字中有Bob这个词的员工，查询返回的最大结果限制为100。

希望这回答了你的问题。

URI严格分为分层部分（路径）和非分层路径（查询），并且两者都用于标识资源。

URI 规范本身（RFC 3986）清楚地将 URI 的路径和查询部分视为相等。

第3.3节：

The path component contains data [...] that along with [the] query component serves to identify a resource.

第3.4节：

The query component contains [...] data that, along with [...] the path component serves to identify a resource

所以，在使用x/y/z和x=val&y=val&z=val之间做出选择的主要因素是x、y或z是否具有分层性质，或者它们是否是非分层性质，以及您是否可以预见它们在可预见的未来始终具有分层性还是非分层性，并考虑选择一个而非另一个可能存在的任何技术限制。

但是回答你的问题，正如其他人所指出的：两者都一样符合REST原则，因为它们最终都能识别出一个资源。

如果资源是服务，独立于参数，则应该。

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

这是一个GET请求。REST的原则之一是，您可以GET阅读（但不能修改！）资源；您可以POST修改资源并获取响应；您可以PUT编写资源；您可以DELETE删除资源。

如果使用这些参数特定的资源是持久化资源，它需要一个名称。如果您以这种方式组织您的Web服务，您可以POST到http://myservice.example.com/service?x=val&y=val&z=val来创建特定服务的一个实例，并将其返回一个ID来命名此实例，例如。

http://myservice.example.com/service/12312549

然后使用GET / POST / PUT / DELETE与该实例进行交互。

首先，将URI定义为API的一部分会违反REST架构的一个约束条件。您不能这样做并称其为RESTful API。

其次，查询参数用于非查询资源访问的原因是它们通常不会被缓存，这也违反了HTTP标准。

像/x/y/z/这样有斜杠的URL会强制使用层次结构，不适合仅传递三个参数的确切情况。

如果像你说的那样，x y z 确实只是参数，而顺序并不重要，那么使用分号会更符合 RESTful 的规范：

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

如果你的“服务”只是一个使用不同参数相同算法的算法，那么使用?x=val格式也不会违反RESTful规则。