如何处理 REST 异常？
我们正在讨论如何处理 REST 异常。
响应内容类型：JSON
我们有两种解决方案：
- 将所有未经检查的异常作为 JSON 响应抛出。
- 发送请求无效的响应代码。
参数：
- 当出现错误时，为什么返回 JSON？只需发送无效的响应代码。
反驳观点：
- 响应代码技术性太强，普通开发人员无法处理。
你说什么？
We are in the middle of a ongoing discussion about how to handle REST exceptions.
Response Content type : JSON
Two solutions we have:
- Throw all the unchecked exceptions as a JSON response.
- Send Request Invalid Response code.
Arguments:
- When its a error, why return JSON? Just send a invalid response code.
Counter Argument:
- Response code are too technical to handle for normal developers.
Whats your say??
如果你对这篇内容有疑问，欢迎到本站社区发帖提问 参与讨论，获取更多帮助，或者扫码二维码加入 Web 技术交流群。
绑定邮箱获取回复消息
由于您还没有绑定你的真实邮箱，如果其他用户或者作者回复了您的评论，将不能在第一时间通知您！
发布评论
评论（3）
对于我最近开发的 JSON API，我同时执行了这两种操作。我总是使用有效的 JSON 进行响应（好吧，假设我做出了响应）。如果我检测到无效请求，我会使用状态 400。如果我检测到服务器错误（我不认为这是由无效请求引起的），我会使用 5xx 状态。 JSON 对象包含一个仅针对错误设置的特殊键和一个字符串值。
我认为这是一个很好的解决方案，尊重 REST 原则，并且可以多种方式使用。其他一些 JSON API 使用相同的解决方案，例如 Yahoo Search。尝试 http://search.yahooapis.com/ImageSearchService/V1/ imageSearch?appid=YahooDemo&output=json 。
For a JSON API I recently developed I do both. I always respond with valid JSON (well, assuming I respond at all). If I detect an invalid request, I use status 400. If I detect a server error (which I don't believe is caused by an invalid request), I use a 5xx status. The JSON object contains a special key that is only set for errors, with a string value.
I think this is a good solution that respects REST principles, and can be used in multiple ways. The same solution is used by some other JSON APIs, such as Yahoo Search. Try http://search.yahooapis.com/ImageSearchService/V1/imageSearch?appid=YahooDemo&output=json .
使用类似于 HTTP 的错误代码。因此，对于由某些内部问题引起的任何异常，50*。糟糕的论点则为 40*。尽可能避免使用您自己定义的代码。这个想法是有一个“统一”的界面。
一般来说。
204 表示成功，不发送任何内容
200 表示成功使用资源的 json 表示形式
如果操作不成功，则返回适当的响应代码。您可以选择返回 json。为了简化事情，您可以为所有错误响应使用通用格式 (json)。
http://en.wikipedia.org/wiki/REST 是您冻结之前必须阅读的内容你的 API 规范。
Use error codes like for HTTP. So 50* for any exception cause by some internal problem. And 40* for bad arguments. Avoid using your own defined codes as far as its possible. The idea is to have a "uniform" interface.
In general.
204 for success without sending any content
200 for success with a json representation of the resource
And if its not a successful operation return appropriate response code. You can choose to optionally return a json. To simplify things you can have a common format (json) for all error responses.
http://en.wikipedia.org/wiki/REST is a must read before you freeze on your api specs.
对于使用 REST 的开发人员来说，提供所需的尽可能多的信息会很有帮助，但不能超过这个范围。您不想透露太多有关您的基础设施的信息，是吗？因此，您可能需要区分以下各项：
如果端点不存在如果某个内部系统（例如数据库关闭或数据库登录失败），则返回 500，如果未找到 URI，则返回 404、200 或 204（争论仍在继续），但我更喜欢带有空的 200表示资源列表的 URI 的结果为空，但当需要特定资源但未找到时，会出现 404。在所有这些情况下，您可能会提供对消费者端的开发人员有帮助的不同正文消息。
因此，您可能想要准确地区分发生了什么异常：上游错误报告对消费者来说是无用的，例如数据库错误，或者与消费者非常相关的接口错误，例如包含未知的查询字符串属性。
For the developers consuming your REST it is helpful to provide as much information as needed but not more than that. You don't want to disclose too much information on your infrastructure do you? So you might want to distinguish between:
If an endpoint does not exist this would be a 404, if some internal system, e.g. a database is down or database logon fails a 500 and if the URI is not found a 404, 200 or a 204 (the debate is ongoing) but I prefer a 200 with an empty result for a URI representing a list of resources being empty but a 404 when a specific resource was required and not located. In all these cases you might provide a different body message helpful to the developer on the consumer end.
So you might want to distinguish exactly what exception occurred: an upstream error reporting is useless to the consumer, e.g. database errors, or an interface error which is very relevant to the consumer, like a query string containing unknown attributes.