REST API最佳实践：放置参数的位置？
REST API至少有两种参数：
/api/resource/parametervalue ） /api/resource?parameter=value ） 这里最好的做法是什么？ 关于何时使用1以及何时使用2，有没有一般的指导原则？
真实世界的例子：Twitter使用查询参数来指定时间间隔。 （ http://api.twitter.com/1/statuses/home_timeline.json?since_id=12345&max_id=54321 ）
将这些参数放在URL路径中会被认为是更好的设计吗？
如果有文件记录的最佳实践，我还没有找到它们。 但是，在确定将参数放入网址的位置时，以下是一些准则：
可选参数往往更容易放入查询字符串中。
如果你想在参数值不符合现有资源时返回一个404错误，那么我会倾向于一个路径段参数。 例如/customer/232 ，其中232不是有效的客户ID。
如果你想要返回一个空列表，那么当没有找到该参数时，我建议使用查询字符串参数。 例如/contacts?name=dave
如果参数影响URI空间的整个子树，则使用路径段。 例如语言参数/en/document/foo.txt与/document/foo.txt?language=en
我更喜欢唯一标识符位于路径段而不是查询参数。
URI的官方规则可在此RFC规范中找到。 这里还有另一个非常有用的RFC规范，它定义了参数化URI的规则。
迟到的答案，但我会添加一些额外的见解，分享什么，即有几种类型的“参数”的请求，你应该考虑到这一点。
现在我们来看看这些参数可能出现的不同位置。
一般来说，你希望状态设置在标题或cookie中，具体取决于它是什么类型的状态信息。 我想我们都可以同意这一点。 如果需要的话，使用自定义http头（X-My-Header）。
同样，Content只有一个地方属于请求正文，可以是查询字符串，也可以是http multipart和/或JSON内容。 这与您向服务器发送内容时从服务器收到的内容一致。 所以你不应该粗鲁，而是以不同的方式去做。
诸如“id = 5”或“action = refresh”或“page = 2”之类的定位器将具有URL路径的意义，比如mysite.com/article/5/page=2 ，其中一部分您知道每个部分应该是指（基本上如文章和5显然意味着让我的类型文章的数据与id 5）和额外的参数被指定为URI的一部分。 如果您知道在URI中的某个点之后“文件夹”是配对的键值，它们可以是page=2或page/2的形式。
过滤器始终放在查询字符串中，因为虽然它们是查找正确数据的一部分，但它们仅用于返回Locators返回的子集或修改。 在mysite.com/article/?query=Obama （子集）中的搜索是一个过滤器，所以/article/5?order=backwards （修改）。 想想它的作用，而不仅仅是它叫什么！
如果“视图”确定输出格式，那么它是一个过滤器（ mysite.com/article/5?view=pdf ），因为它返回对找到的资源的修改，而不是归入我们想要的资源。 如果它决定了我们看到的文章的哪一部分（ mysite.com/article/5/view=summary ），那么它就是一个定位器。
请记住，缩小一组资源是过滤。 在某个资源中查找特定内容正在查找... duh。 子集过滤可以返回任意数量的结果（甚至是0）。 定位将始终找到某个特定的实例（如果存在）。 修改过滤将返回与定位符相同的数据，除了已修改（如果允许这样的修改）。
希望这有助于给人们一些尤里卡的时刻，如果他们已经失去了把东西放在哪里！
这取决于设计。 HTTP上的REST没有URI的规则（主要是它们是唯一的）。 往往涉及品味和直觉的问题......
我采取以下方法：