REST：为什么要公开 POST 和 API 的 PUT 端点，而两者都可以通过这些端点中的任何一个来完成？
REST: Why expose POST and PUT endpoint of API when both can be done with just any one of these endpoints?
我们正在创建一个电子商务网站，几个卖家可以通过 API 公开展示他们的产品。每个卖家对于他们随每个请求发送的每个产品都有自己的唯一标识符 (product_id + seller_id)。因此，他们不依赖我们系统生成的 "product id" 在 POST.
之后发送 PUT 请求
对于我们的每个客户，我们必须告诉他们仅针对尚未创建的股票发送 POST，仅针对已创建的股票发送 PUT。客户需要记录所有已创建的股票，并据此决定要命中哪个 API。在 API 方面，如果我们得到 POST 已经存在的库存或 PUT 不存在的库存，我们也会发送验证错误。
我想了解为什么我们必须在客户端和服务器上保持这种复杂性，如果我们根据情况选择这些请求中的一个 CREATE/UPDATE 本来可以简化事情。
例如只选择POST。如果请求到来但它不存在，我们将创建产品，或者如果它已经存在，我们将更新它。
为什么 REST 建议单独保留 POST/PUT？
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 明显不同，因此您无论如何都需要不同的处理程序。
我们正在创建一个电子商务网站，几个卖家可以通过 API 公开展示他们的产品。每个卖家对于他们随每个请求发送的每个产品都有自己的唯一标识符 (product_id + seller_id)。因此，他们不依赖我们系统生成的 "product id" 在 POST.
之后发送 PUT 请求对于我们的每个客户，我们必须告诉他们仅针对尚未创建的股票发送 POST，仅针对已创建的股票发送 PUT。客户需要记录所有已创建的股票，并据此决定要命中哪个 API。在 API 方面，如果我们得到 POST 已经存在的库存或 PUT 不存在的库存，我们也会发送验证错误。
我想了解为什么我们必须在客户端和服务器上保持这种复杂性，如果我们根据情况选择这些请求中的一个 CREATE/UPDATE 本来可以简化事情。
例如只选择POST。如果请求到来但它不存在，我们将创建产品，或者如果它已经存在，我们将更新它。
为什么 REST 建议单独保留 POST/PUT？
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 明显不同，因此您无论如何都需要不同的处理程序。