如何验证 REST 请求？
给定此服务：
POST /hotel HTTP/1.1
<hotel>
<a>aaa</a>
<b>bbb</b>
<c>ccc</c>
</hotel>
HTTP/1.1 201 CREATED
Location: /hotel/123
当我们在服务器上处理请求时，我们将根据 DTD 验证请求中的 hotel XML。
问题是，作为 REST 最佳实践，客户端是否应该在请求中引用 DTD（就像在基于 DTD 创建 XML 文档时通常所做的那样）？或者这不是必需的？ DTD 将在 API 文档中进行描述，以便客户端服务的编写者能够了解 DTD 验证详细信息。
Given this service:
POST /hotel HTTP/1.1
<hotel>
<a>aaa</a>
<b>bbb</b>
<c>ccc</c>
</hotel>
HTTP/1.1 201 CREATED
Location: /hotel/123
When we process the request on the server we will validate the hotel XML in the request against a DTD.
Question is, as a REST best practice should the client refer to the DTD in the request (as one normally does when creating an XML doc based on a DTD)? Or is this not required? The DTD will be described in the API docs so the writers of the client service will be aware of the DTD validation details.
如果你对这篇内容有疑问，欢迎到本站社区发帖提问 参与讨论，获取更多帮助，或者扫码二维码加入 Web 技术交流群。
绑定邮箱获取回复消息
由于您还没有绑定你的真实邮箱，如果其他用户或者作者回复了您的评论，将不能在第一时间通知您！
发布评论
评论（2）
据我所知，REST 对 POST 正文的内容没有任何说明。
显然，无论如何您都必须在服务器上验证 XML，因此您能做的最好的事情就是建议客户端在发送 XML 之前根据 DTD 验证 XML，以节省时间和带宽。然而，你确实没有办法强制执行。
我认为作为服务编写者，您的责任是接受请求，无论它是否涉及 DTD，但这只是我的观点。
To my knowledge, REST does not have anything to say on the contents of the POST body.
Obviously, you have to validate the XML on the server anyway, so the best you can do is recommend that the client validates the XML against the DTD before sending it, to save on time and bandwidth. However, you really have no way to enforce it.
I think your responsibility as a service writer is to accept the request whether or not it refers to the DTD, but that is just my opinion.
好吧，如果请求正文未通过 DTD 检查，您当然可以返回
400 Bad Request，但我不要求存在 DTD 引用。您应该允许省略它，并在存在时使用它，但如果他们指定了错误的 DTD，我也会使请求失败。当然，错误消息应该指出预期的 DTD 是什么。如果省略 DTD，您可能需要考虑跳过严格的一致性检查，因为这更像是人们在设置软件时想要的东西，但出于性能原因，可能希望在知道一切都已完成后就关闭在职的。
Well, you could certainly spit back a
400 Bad Requestif the request body fails a DTD check, but I wouldn't require the DTD reference to be present. You should allow it to be omitted, and use it if it's there, but I would also fail the request if they specify the wrong DTD. The error message should, of course, indicate what the expected DTD is.You might want to consider skipping the strict conformance check if the DTD is omitted, since it's more the sort of thing that people want when they're setting up the software, but for performance reasons, might want to have off after they know everything is working.