REST：应该PUT总是接受GET之前返回的内容
共有1个答案
当您执行get请求时，您要求的是资源的表示形式。当您执行put请求时，您要求用提交的表示形式中的资源替换目标资源。
因此，如果两种表示都使用相同的媒体类型，服务器应该接受它，但是完全可以使用一种媒体类型来表示put，而使用另一种媒体类型来表示get。
服务器是否应该允许客户机读取(GET)一个在更新时发送(PUT)时本身被标记为无效的资源？
-
我有一个使用swagger UI的swagger标记文档，它总是返回text/html，但应该返回application/json。POST请求和其他类型返回Application/JSON，但这个特定的GET请求不返回。服务endpoint代码正确。如果我将请求更改为POST,它将返回application/json。因此，在swagger中只有type GET不返回正确的类型。有什么想法，如何
-
这方面的最佳实践是什么。NET与Web API？特别是WebRESTAPI。当异常发生时，RESTAPI是否应该在响应体中返回异常？ 当然，我会返回500或类似的HTTP状态。但是当我用这个错误代码响应时，最佳实践是什么？或者更好的是，规范或RESTAPI对此有何规定？ 返回异常（我所做的）
-
为了尊重REST原则的最佳实践，是否最好在POST/PUT时返回创建/更新的实体？还是用Location头返回一个空的HTTP体？ 更准确地说，当一个资源由一个帖子创建时，我们应该返回： 状态201位置标头（HTTP正文中创建的实体） 或 状态 201 位置标头（空正文） 当一个资源被PUT更新时，我们是否应该返回： 状态200（HTTP主体中的更新实体） 或 状态 204（空正文）
-
问题内容： Java8引入了这些不错的方法和，从而允许编写如下代码： 现在，我想知道是否有充分的事实理由可以这样做： 要么 两者都可以工作： 当 将元素添加到列表 时，选项1可能会进行很多不必要的“ put”调用 选项2可能做了很多不必要的“的containsKey”呼叫时 对新的密钥添加新条目 是主导 SO：“总是”选择选项1或选项2的充分理由是吗？ 问题答案： 如果您想对替代值使用缺席值而不修
-
问题内容： 我正在使用RESTlet，并且已经创建了资源。我通过覆盖方法处理POST 。 客户端应该向我发送一些数据，然后将其存储到DB，将响应设置为201（SUCCESS_CREATED），我需要向客户端返回一些数据，但是返回类型为。 就我而言，我需要返回一些标识符，以便客户端可以访问该资源。 例如，如果我有一个带有URL的资源，并且客户端发送了POST请求，则在DB中添加一个新行，其地址应为。
-
我有以下Rest服务API来更新“朋友”数据集： 当我尝试将更新的对象“朋友”通过使用Spring restTemboard这样： 我得到一个HTTP 400 BadRequest错误。 我不知道为什么会这样。你有什么建议吗？