我们正在创建一个电子商务网站，其中有几家卖家会通过公开的API推送他们的产品。每个卖家都有自己的唯一标识符，用于每个产品（product_id + seller_id），并随每个请求一起发送。因此，他们不依赖于＆＃34;产品ID＆＃34;我们的系统在POST后发送PUT请求。
对于我们的每个客户，我们必须告诉发送POST仅针对已经未创建的股票，PUT仅针对已创建的股票。客户需要记录所有已创建的库存，并根据该库存决定要使用哪种API。在API方面，如果我们获得现有库存的POST或不存在库存的PUT，我们会发送验证错误。
我想理解为什么我们必须在客户端和服务器上保持这种复杂性，如果我们根据情况选择其中一个可以创建/更新的请求，那么事情就可以简化了。
例如，如果只选择POST。我们将在请求到来时创建产品并且它不存在或者如果它已经存在则更新它。
为什么REST建议单独保留POST / PUT？
答案 0 :(得分：2)
PUT和POST存在语义差异。首先考虑执行请求的URI：
POST /products
这增加了一个新产品。生成的产品ID尚不清楚，将在添加到数据库时生成。两次发布相同的产品将导致目录中的两个完全相同的条目。这可能是REST API中的故意行为。 （可能不是你的情况。）
PUT /products/235647
这会更新现有产品。 id已为客户端所知，这可确保仅更新该资源。针对URI的POST没有多大意义。
如果要向元素添加更多数据，可以使用更具体的URI：
POST /products/235647/reviews
然后更新该数据：
PUT /products/235647/reviews/2
分离Create和Update动词可确保有意创建重复项，而不是错误地创建重复项。 URI也是显着不同的，因此无论如何你需要不同的处理程序。