回答晚了，但我将对已经分享的内容添加一些额外的见解，即请求有几种类型的“参数”，您应该考虑到这一点。

定位器——例如资源标识符，如id或操作/视图 过滤器——例如，提供搜索、排序或缩小结果集的参数。 状态-例如会话标识，api密钥，等等。 内容-例如要存储的数据。

现在，让我们看看这些参数可能发生的不同情况。

请求报头和cookie URL查询字符串("GET"变量) URL路径 正文查询字符串/多部分("POST" vars)

通常，您希望在头文件或cookie中设置State，这取决于它是哪种类型的状态信息。我想我们都同意这一点。如果需要，使用自定义http报头(X-My-Header)。

类似地，Content只有一个归属位置，即在请求体中，可以作为查询字符串，也可以作为http multipart和/或JSON内容。这与服务器向您发送内容时您从服务器接收到的内容一致。所以你不应该无礼，用不同的方式去做。

像“id=5”或“action=refresh”或“page=2”这样的定位器作为URL路径是有意义的，例如mysite.com/article/5/page=2，其中您部分知道每个部分的含义(例如article和5显然意味着为我获取id为5的article类型的数据)，并且附加参数被指定为URI的一部分。它们的形式可以是page=2，或者page/2，如果您知道URI中的某个点之后，“文件夹”是成对的键-值。

过滤器总是在查询字符串中，因为尽管它们是查找正确数据的一部分，但它们只是返回Locators单独返回的数据的子集或修改。在mysite.com/article/?query=Obama(子集)中的搜索是一个过滤器，/article/5?顺序向后=(修改)。想想它是做什么的，而不仅仅是它的名字!

如果“view”决定输出格式，那么它是一个过滤器(mysite.com/article/5?view=pdf)，因为它返回对找到的资源的修改，而不是指向我们想要的资源。如果它决定我们可以看到文章的哪个特定部分(mysite.com/article/5/view=summary)，那么它就是一个定位器。

记住，缩小一组资源就是筛选。在资源中定位某个特定的东西就是定位…咄。子集筛选可以返回任意数量的结果(甚至是0)。定位总是会找到某事物的特定实例(如果它存在)。修改筛选将返回与定位器相同的数据，除了被修改(如果允许这样的修改)。

如果人们不知道该把东西放在哪里，希望这能给他们一些顿悟的时刻!

作为一名经常在客户端工作的程序员，我更喜欢使用查询参数。另外，对我来说，它将URL路径从参数中分离出来，增加了清晰度，并提供了更多的可扩展性。它还允许我在URL/URI构建和参数构建器之间有单独的逻辑。

我很喜欢曼努埃尔·阿尔达纳说的另一种选择如果有某种树的话。我可以看到用户特定的部分被树形分开。

我通常倾向于#2，作为查询参数(即/api/resource?=参数值)。

第三种选择是将parameter=value放到函数体中。

这是因为它可以更好地用于多参数资源，并且具有更强的可扩展性以供将来使用。

不管你选哪一个，确保你只选一个，不要混搭。这导致了一个令人困惑的API。

这个主题的一个“维度”被忽略了，但它非常重要:有时“最佳实践”必须与我们正在实现或增强REST功能的平台相一致。

实际的例子:

现在许多web应用程序都实现了MVC(模型、视图、控制器)架构。他们假设提供了一个特定的标准路径，当那些web应用程序带有“启用SEO url”选项时更是如此。

这里只提一个相当有名的网络应用程序:OpenCart电子商务商店。 当管理员启用“SEO url”，它期望说url来一个相当标准的MVC格式，如:

http://www.domain.tld/special-offers/list-all?limit=25

在哪里

special-offers是处理URL的MVC控制器(显示special-offers页面) List-all是控制器要调用的动作或函数名。（*） Limit =25是一个选项，表示每页将显示25个项目。

(*) list-all是我使用的一个虚构的函数名。实际上，OpenCart和大多数MVC框架都有一个默认的、隐含的(通常在URL中省略)索引函数，当用户想要执行默认操作时，就会调用该索引函数。真实世界的URL是:

http://www.domain.tld/special-offers?limit=25

现在有了一个类似于上面的相当标准的应用程序或框架结构，你经常会得到一个针对它进行优化的web服务器，为它重写URL(真正的“非SEOed URL”应该是:http://www.domain.tld/index.php?route=special-offers/list-all&limit=25)。

因此，作为开发人员，你要面对的是处理现有的基础设施，并适应你的“最佳实践”，除非你是系统管理员，确切地知道如何调整Apache / NGinx重写配置(后者可能很讨厌!)等等。

因此，你的REST API通常会更好地遵循参考web应用程序的标准，无论是一致性还是易用性/速度(从而节省预算)。

回到上面的实际例子，一个一致的REST API应该是类似这样的url:

http://www.domain.tld/api/special-offers-list?from=15&limit=25

或者(非SEO URLs)

http://www.domain.tld/index.php?route=api/special-offers-list?from=15&limit=25

使用“路径形成”参数和“查询形成”参数的混合。

这取决于设计。HTTP上的REST没有uri规则(主要是它们是唯一的)。通常这涉及到品味和直觉的问题……

我采取以下方法:

url path-element:资源和它的path-element组成了一个目录遍历和一个子资源(例如/items/{id}， /users/items)。不确定的时候问问你的同事，如果他们认为遍历和他们认为在“另一个目录”最有可能的路径元素是正确的选择 Url参数:当没有遍历时(有多个查询参数的搜索资源就是一个很好的例子)

以下是我的观点。

查询参数被用作请求的元数据。它们充当现有资源调用的过滤器或修饰符。

例子:

/ / 2014-08-08 /日历事件

应该给出当天的日历事件。

如果需要特定类别的事件

/日历/ 2014-08-08 /事件吗?类别=约会

或者你需要超过30分钟的比赛

/日历/ 2014-08-08 /事件吗?时间= 30

试金石测试是检查在没有查询参数的情况下是否仍然可以提供请求。