所以基于我最近关于REST API接口的大量研究，我有一个理论问题。
首先我理解在REST中，资源应该是名词而不是动词，每个资源应该与下一个资源分离，但是资源可以返回相同的实体或实体集合，具体取决于资源的用途。 / p>
然而，我的重点是进行宁静的搜索。
在我所做的所有研究中，我遇到的最常见的解决方案是使用URL中的参数
api.test.com/search-cars?param1=val1¶m2=val2
虽然这是标准做法并且没有真正违反REST的规则，但为什么没有人将搜索参数表示为id（可能以JSON的形式）
api.test.com/cars/{"color":"blue","year":"2013","make":"toyota"}
如果我将汽车视为一种资源并将我的身份称为JSON，我可以很容易地说我真的拥有有限数量的汽车，因此这是一个有限且独特的id。
此外，通过符合“resource / id”
，这可以促进纯粹的休息在第一个示例中使用参数有什么好处和缺点？
在第二个示例中，使用JSON作为带有“过滤器”的id有什么好处和缺点？
您的所有评论都非常有用，因为我需要就如何推进API的第一个资源做出最终决定。另外，我需要为我的老板提供一个强有力的论据，解释为什么我决定使用其中一种方法。
答案 0 :(得分：3)
网址的一般形式是
scheme://domain:port/path?query_string#fragment_id
所以你建议两个网址：
query_string搜索path段query_string搜索我建议将集合命名为cars，而不是search-cars。在您撰写问题时，URL会识别资源。 cars资源标识所有汽车的集合。我不知道名为search-cars的资源会识别哪个集合。
GET http://api.test.com/cars
将返回所有汽车的集合。
GET http://api.test.com/cars/123
将返回123标识的汽车。
GET http://api.test.com/cars?color=blue&year=2013
将返回2013年所有蓝色车型的集合。
path搜索您的第二个网址
GET http://api.test.com/cars/{"color":"blue","year":"2013","make":"toyota"}
会使查询（JSON）成为路径的一部分。为了使两个示例相等，我想将JSON设为查询参数：
GET http://api.test.com/cars?search={"color":"blue","year":"2013","make":"toyota"}
大多数REST框架都支持将查询参数映射到方法参数。
大多数REST框架允许您将路径段映射到方法参数。而且，大多数REST框架允许您将JSON映射到对象或简单字典。
使JSON更难使用的原因是需要转义"{}个字符：
{"color":"blue","year":"2013","make":"toyota"}
变为
%7B%22color%22%3A%22blue%22%2C%22year%22%3A%222013%22%2C%22make%22%3A%22toyota%22%7D
这不是很好。
query_string和path来标识资源。搜索参数最好放在query_string中，因为?可以在精神上转换为SQL的WHERE。