在Web服务器上删除时发布或放置而不是删除
我们有一个带有帖子，放置，删除和获取方法支持的CRUD API。此后，我们发现删除在我们组织的Web服务器级别上被阻止，因此通过浏览器删除的任何请求都会阻止API的任何请求。我们被告知将API更新到支持DELETE的帖子。在删除请求中，我们的API随后拨打另一个API，其中包含支持的删除请求。
因此流量是
浏览器 - ＆gt; put/post-＆gt; Ourapi - ＆gt;删除 - ＆gt;另一个
旧URI被删除/{entity}/{code}
我正在更新为/{entity}/{code}/delete - 但不确定是否有意义作为看台或发布的，我知道帖子不是愿意的，但是第二个API的删除请求将是。
谢谢
We have an crud API developed with POST, PUT, DELETE and GET methods supported. We have since discovered that DELETE is blocked at web server level in our organization so any requests to the API for DELETE via browser are blocked. We were informed to update our API to a POST for supporting DELETE. In the delete request Our API then calls another API with a DELETE request which is supported.
So the flow is
browser -> PUT/POST -> ourAPI -> DELETE -> anotherAPI
The old URI was DELETE /{entity}/{code}
I am updating to /{entity}/{code}/delete - but unsure if it makes more sense as a PUT or POST, I know POST isn't idempotent but the DELETE request to second API will be.
Thanks
如果你对这篇内容有疑问，欢迎到本站社区发帖提问 参与讨论，获取更多帮助，或者扫码二维码加入 Web 技术交流群。
绑定邮箱获取回复消息
由于您还没有绑定你的真实邮箱，如果其他用户或者作者回复了您的评论，将不能在第一时间通知您！
发布评论
评论（2）
是否要使用帖子或PUT取决于如何处理不存在的实体的尝试。
如果请求应该像实体存在一样静静地成功，则该诉讼是愿意的 - 因此，看来似乎是适当的。
如果请求应触发错误（404或至少服务器端日志记录），则POST似乎合适。
Whether to use POST or PUT could depend on how attempting to delete a non-existent entity should be handled.
If the request should succeed silently as if the entity existed, the action is idempotent - so PUT seems appropriate.
If the request should trigger an error (404 or at least server-side logging), POST seems appropriate.
只要对用户清楚，这并不重要。
这是此网站删除的帖子的示例和示例： /a>。
It doesn't really matter as long as it's clear to the users.
Here's and example of a POST delete from this very site: https://api.stackexchange.com/docs/delete-answer.