我正在查看 REST API 的规范,并且设计人员针对错误情况提供了以下响应 json 正文...
{
"status": "",
"serviceSpecErrorCode": "",
"userMessage": "",
"devMessage": "",
"moreInfo": ""
}
哪里"status"
是 HTTP 响应代码的副本(例如 404)。
这样做是不好的做法吗?这样做有什么理由/好处吗?
编辑 1:我应该提到,这是一个尚未实现的规范。我问的原因更多是为了最佳设计/实践,因为我们现在可以在实施之前改变它。
编辑 2:抱歉,根据一些答案,我还应该提到一件事......该"status"
值将与 HTTP 响应代码相同/相同。他们永远不会不同。
这是多余的。它复制了 HTTP 状态代码本身中可用的信息,从而带来了两者之间不一致的可能性。
如果包含在响应负载中,状态代码应该只是建议性的,并且必须与实际 HTTP 响应中的状态代码相同。
返回 HTTP API 的问题详细信息时,您可能需要查看RFC 7807:
本文档将“问题详细信息”定义为一种在 HTTP 响应中携带机器可读错误详细信息的方式,以避免需要为 HTTP API 定义新的错误响应格式。
根据此类文档,除了其他元素外,问题详细信息对象还可以包含 HTTP 状态代码:
status
(number):源服务器为此次问题生成的 HTTP 状态代码。
RFC 还声明了以下内容:
该
status
成员(如果存在)仅是建议性的;它传达了为方便消费者而使用的 HTTP 状态代码。生成器必须在实际的 HTTP 响应中使用相同的状态代码,以确保不理解此格式的通用 HTTP 软件仍然正确运行。
该
status
成员复制了 HTTP 状态代码本身中可用的信息,从而带来了两者之间不一致的可能性。它们的相对优先级并不清楚,因为分歧可能表明(例如)中间人在传输中修改了 HTTP 状态代码(例如,通过代理或缓存)。
本文收集自互联网,转载请注明来源。
如有侵权,请联系[email protected] 删除。
我来说两句