我正在创建一个API，我想知道为什么在PUT的URI中有一个id参数是常见的？
例如PUT /cars/5
为什么没有PUT /cars？请求实体包含一个id字段是不够的？我可以从该实体获取id，或者它是否有一些缺点，并且它被认为是不好的吗？
答案 0 :(得分：4)
因为如果您要向PUT发送/cars请求，从语义上来说这意味着您正在尝试修改汽车集的属性，而不是修改属性一辆汽车 RESTful API中的URI应指示操作正在执行的确切资源，因此，如果要修改资源，则URI应准确指示该资源。
此外，来自RFC 2616：
PUT请求中的URI标识请求附带的实体 - 用户代理知道预期的URI，服务器不得尝试将请求应用于其他资源。
因此规范表明，如果客户端知道资源的唯一ID，它应该包含在URI中。
答案 1 :(得分：2)
这来自rest“意识形态”。
这个想法是一个url唯一地表示一个实体 - 所以你必须将你正在创建/编辑的实体PUT到该实体的url。
引用维基百科页面：
资源识别
在请求中标识单个资源，例如在基于Web的REST系统中使用URI。资源本身在概念上与返回给客户端的表示是分开的。
答案 2 :(得分：2)
PUT旨在为一个精确的实体提供帮助。
仅使用/cars，您就不会专注于特定的实体。
与你所写的相反，你的完整实体不会以基本字符串（URI）传递。
如果您的定位方法专注于硬编码car id，则例外情况......但我不这么认为......
答案 3 :(得分：2)
归结为API接口。 API设计有几种方法。而且，就像你建议的那样，你可以将id留在请求之外。但是，由于许多API设计都是以您描述的方式构建的，例如PUT / cars / 5，因此它被认为是一种很好的做法。
基本上，您有8种方式与API进行交互。 GET，POST，PUT，DELETE和可选的HEAD。 （如果算上头，则总数将为9或10，具体取决于相互作用）。
所以，要清除它，你有2种GET方式。 GET / cars将检索所有汽车，GET / cars / 5将检索任何ID为5的汽车。因此，您有两种使用GET的方法。 POST，PUT和DELETE也是如此。 4 * 2 = 8对吧？
现在，有些人会说PUT /汽车会变得暧昧，但是在没有额外ID字段的情况下你完全有效，因为正如你所提到的，你已经在请求中传递了ID字段。
Apigee的人们一直在研究API设计。我建议观看他们的一些视频，以更好地理解API设计的含义以及为什么有些参数是有效的，而其他参数则不然。