json – 应该在Restful错误响应中使用HTTP状态吗?

前端之家收集整理的这篇文章主要介绍了json – 应该在Restful错误响应中使用HTTP状态吗?前端之家小编觉得挺不错的,现在分享给大家,也给大家做个参考。
我正在写一个Restful API,我必须返回错误信息,但我不确定要走哪条路线.

路由1 – HTTP状态

客户端发送错误数据时使用HTTP错误状态

例如:401 – 未授权,410 – 模型不存在,412 – 模型Validaiton错误

路由2 – JSON成功或错误失败

API返回json,我正在考虑使用http标头200返回所有内容,但后来我的JSON句柄错误和成功

例如:
{“status”:“错误”,“消息”:“模型验证错误”,“数据”:[“需要用户名”,“需要用户电子邮件”]}

我应该走哪条路?为什么?的优点和缺点.

解决方法

I’m writing a Restful API and I have to return error message but I’m
not sure on which route to go.

Route 1 – HTTP Status

Use HTTP error status when the client sends bad data

HTTP状态代码绝对应该在声称是RESTful的任何Web服务实现中使用.规范的核心原则是利用和扩展Web以完全支持代表状态的转移.为了与现有Web基础结构进行互操作,REST实现应通过适当的HTTP状态代码指示请求的状态.例如:

200 – 好的
201 – 内容创建
401 – 未经授权
403禁止
500 – 服务器错误
501 – 未实施

当响应许多这些状态时,HTTP规范也允许它在响应主体中包含实体表示.在“正常”,非错误响应的情况下,该表示通常是由HTTP请求“操作”的实体.在错误响应的情况下,表示(如果包括)应提供有关发生的错误的更多信息.这是我们选择2的选择.

Route 2 – JSON Success or Error Failure

The API returns json and I am considering returning everything with
the http header 200,but then in my JSON handle errors and success

对于所有回复,您绝对不应该返回200 OK.许多实现良好的HTTP客户端依赖于响应中的状态代码来确定它是否成功.始终以200 OK响应可能导致第三方客户端库错误地处理传入数据,并且还要求客户端解析响应正文以确定错误是否实际发生.

话虽如此,添加有关发生的错误的其他信息可能非常有用,所以一定要考虑将其添加到响应主体.您建议的格式看起来很好,但说实话,状态元素是多余的,假设您正确使用HTTP状态代码.更像是:

{
    "message": "Model validation error","data": [
        "user name required","user email required"
    ]
}
原文链接:https://www.f2er.com/js/158429.html

猜你在找的JavaScript相关文章