Error messages from REST requests
I am helping to design a RESTful API for the Drupal CMS (http://drupal.org/). As part of that, we want to support multiple formats (mime types) on a given data object (resource). All well and good.
However, we're not sure what the best practice is for error handling. Specifically, in what format should we return error messages in case of 403, 404, or 500 errors, and to what degree does it matter?
My initial thought of course is "in the format that was requested, duh". However, that implies a great deal of per-format work to ensure a proper envelope. For instance:
application/json:
{ 'error': "The framistan broke and we cannot find that object." }
application/json-ld+json
{ '@context': {something here}, '@error': "The framistan broke and we cannot find that object." }
application/xml
<error>
<message>The framistan broke and we cannot find that object.</message>
</error>
application/atom+xml [same as application/xml, but with 20 lines of Atom wrapper markup]
application/svg+xml
<svg>
<text>The framistan broke and we cannot find that object.</text>
</svg>
And so on. And of course a consumer of our API would need to know how we're formatting the error message payload. That's a considerably higher barrier for adding new formats to the system as well as for integrating with our API.
Alternatively, we could just say that errors on mundane formats (ie, not HTML) always return an unformatted text/plain string. So if the system dies while requesting any non-HTML format, you always get back a text/plain message with body "The framistan broke and we cannot find that object.".
That's much easier to develop for, and much easier for the client to support, but it means that a client requesting application/atom+xml could get back a response in text/plain. What's up with that?
Has anyone else run into this question? How did you resolve it? Is there a de facto best practice for how to handle this situation? Is there a spec somewhere that dictates what to do that we can follow? Basically I want to avoid "doing our own thing" as much as possible, particularly in areas of REST APIs.
链接地址: http://www.djcxy.com/p/45338.html下一篇: 来自REST请求的错误消息