相关疑难解决方法(0)

我在这里看到了几个问题,例如如何调试RESTful服务,其中提到:

不幸的是,相同的浏览器不允许我测试HTTP PUT,DELETE,甚至在某种程度上测试HTTP POST.

我也听说过浏览器只支持GET和POST,来自其他一些来源:

• http://www.packetizer.com/ws/rest.html
• http://www.mail-archive.com/jmeter-user@jakarta.apache.org/msg13518.html
• http://www.xml.com/cs/user/view/cs_msg/1098

但是,Firefox中的一些快速测试显示发送PUT和DELETE请求按预期工作 - XMLHttpRequest成功完成,并且请求以正确的方法显示在服务器日志中.我是否缺少某些方面,例如跨浏览器兼容性或非明显的限制？

虽然HTTP 1.1规范似乎允许DELETE请求上的消息体,但它似乎表明服务器应该忽略它,因为它没有定义的语义.

4.3消息正文

服务器应该在任何请求上读取和转发消息体; 如果请求方法不包含实体主体的定义语义,那么在处理请求时应该忽略消息主体.

我已经回顾了有关SO及其他内容的几个相关讨论,例如:

• 实体主体是否允许HTTP DELETE请求？
• HTTP请求方法的有效负载
• 带请求正文的HTTP GET

大多数讨论似乎都同意允许在DELETE上提供消息体,但通常不建议这样做.

此外,我注意到各种HTTP客户端库中的趋势,这些库中似乎记录了越来越多的增强功能,以支持DELETE上的请求主体.大多数图书馆似乎都有责任,尽管偶尔会有一些初步阻力.

我的用例要求在DELETE上添加一些必需的元数据(例如删除的"原因",以及删除所需的一些其他元数据).我已经考虑了以下选项,其中任何一个看起来都不合适,并且与HTTP规范和/或REST最佳实践内联:

• 消息正文 - 规范表明DELETE上的消息体没有语义值; HTTP客户端不完全支持; 不是标准做法
• 自定义HTTP标头 - 需要自定义标头通常违反标准做法 ; 使用它们与我的其余API不一致,其中没有一个需要自定义标头; 此外,没有好的HTTP响应可用于指示错误的自定义标头值(可能是一个单独的问题)
• 标准HTTP标头 - 没有标准标头是合适的
• 查询参数 - 添加查询参数实际上会更改要删除的Request-URI; 违反标准做法
• POST方法 - (例如POST /resourceToDelete { deletemetadata })POST不是删除的语义选项; POST实际上代表了所需的相反操作(即POST创建资源下属;但我需要删除资源)
• 多个方法 - 将DELETE请求拆分为两个操作(例如,PUT删除元数据,然后删除DELETE)将原子操作拆分为两个,可能会留下不一致的状态.删除原因(和其他相关元数据)不是资源表示本身的一部分.

我的第一个偏好可能是使用消息体,第二个是自定义HTTP头; 但是,如上所述,这些方法存在一些缺点.

是否有任何与REST/HTTP标准一致的建议或最佳实践,以便在DELETE请求中包含此类必需的元数据？还有其他我没有考虑的替代方案吗？

我有一个简单的Restful服务从控制台应用程序调用,所以我使用WebClient.我想知道这次删除是否正确.

该URL看起来像localhost/RestService1/Person/1

using (var client = new WebClient()) 
{
    client.UploadString(url, "DELETE", "");
}

我不喜欢UploadString没有数据参数的重载.传递一个空参数并不适合我.有没有更好的方法用于"删除"？

我可以使用WebRequest,但我想只使用WebClient来保持一致.

这是WebRequest块

var request = WebRequest.Create(url);
request.Method = "DELETE";
var response = (HttpWebResponse)request.GetResponse();

两个块都工作正常,但最好的是什么？或者,还有更好的方法？

在REST API中,当需要参数来确定需要删除哪些资源时,我们如何创建DELETE方法？

例如,照片可以属于用户和组,如果我们有照片的端点,我们将需要其他信息来确定我们是否要删除用户照片或组照片,例如,

 /photos?userId={userId}
 /photos?groupId={groupId}

这是一个很好的休息练习吗？

或者,DELETE只能通过用户/:id/photo或groups /:id/photo端点严格执行吗？

我正在开发一个 REST 服务，我的一个服务器端操作以一种可能需要一段时间的方式操作数据库，但是一旦操作开始，数据库就无法恢复（这是来自我们的系统的约束）正在我们的服务器上使用。我也许可以在以后的版本中更改它，但现在我们被这个限制所困）。结果是在允许操作运行之前，我需要一个带有警告的“确定/取消”对话框。

起初我想把创建对话框的逻辑放在客户端，但这似乎违反了 HATEOAS（例如，如果我在服务器端更改框架，则不需要对话框，但我赢了如果我的 API 保持不变，则不想更改客户端）。我的下一个解决方案是返回带有警告的响应，以及链接到不同 POST 操作的 ok，但我不确定何时发送我的参数。我是否在第一个 POST 中发送参数？如果是这样，他们如何进入第二个 POST（当然不保持应用程序状态）？仅将参数发送到第二个 POST 不是一种选择，因为只有 HATEOAS 将确定是否需要第二个。

我在这里发现了一个类似的问题： REST、HTTP DELETE 和参数 但这有两个问题：

1. 它没有解决我们的问题（因为他只在第二次尝试时添加了一个参数，但我需要从第一次开始就随身携带我的参数）。
2. DELETE 必须符合“统一接口”。他确实提出了一个有效的观点，即并非所有客户端都一定需要确认，但是将整个对话框放在 UI 中让我回到我们的问题，如果我改进我的服务器端应用程序会发生什么。

我很高兴听到你对此事的看法。

PS：这是我在stackoverflow.com上的第一篇文章（经过多年使用它来寻找我之前提出的问题的答案），所以如果问题的格式不太正确，请原谅我（欢迎您更正当然是我）。