我正在设计一个REst API，我们的后台资源对象有一个组合作为key，比如account_number+product_type。
我设计的是REst API，我们的后台资源对象有一个组合作为key，比如账号+产品类型，这样的PUT是否可以更新一个账号，用thisPUT: accounts_number+product_type。
{
account_number:1222;
product_type:sn,
;;;;
}
我知道标准的PUT方式是在URI中引用key，只是想知道如果没有key会不会出现什么问题？
PUT更新一个账户是否可以，用这个PUT: accounts
潜在的问题是，请求的意思并不是你认为的那样。
REST架构风格中的一个约束条件是统一接口约束，大体上，这意味着大家对请求的理解是一样的。
PUT，在HTTP中的定义是：用http请求的消息体所包含的表示方式替换目标资源的状态。 参见 RFC 7231
一个给定表示的成功PUT将表明，随后对同一目标资源的GET将导致一个等价的表示以200（OK）的响应方式发送。
换句话说，当您创建一个请求，如
PUT /accounts
{ "account_number":1222, ...
你的意思是说，当有人发送一个 GET /accounts 请求。
从你的问题来看，你可能想要的是，离开了 /accounts 不变，而实际上是在做改变。/accounts/1222 资源。 但这不是 这个 请求说。
真正的危险不是你的服务器会做错事--你控制着你的服务器，而服务器在响应请求时有很大的自由度。
真正的危险是其他通用组件会做错事，因为它们会相信消息的意思是它所说的意思，而不是只有你的服务器才理解的其他东西。
如果由此产生的混乱导致财产损失，每个人都会（正确地）责怪你的服务器对消息语义的不正确解释。
我们说的是什么样的混乱呢？ 规范的 204 没有内容 提供了一个提示：客户端（以及任何其他通用组件）被允许假设204响应中包含的元数据适用于该 目标资源的资源；在这个例子中，元数据将被应用于 /accounts 而非 /accounts/1222.
当然，这样的设计是有问题的，这个故障可能会导致失败，也可能不会导致失败。
在我维护的一个项目中，当我发现这个故障时，我会立即拒绝一个拉取请求。 这和无谓的破坏后向兼容性是一样的。