如果 REST API 返回 JSON，那么什么 MIME 类型？
声明：本页面是StackOverFlow热门问题的中英对照翻译，遵循CC BY-SA 4.0协议，如果您需要使用它，必须同样遵循CC BY-SA许可，注明原文地址和作者信息，同时你必须将它归于原作者（不是我）：StackOverFlow
原文地址: http://stackoverflow.com/questions/404470/
Warning: these are provided under cc-by-sa 4.0 license. You are free to use/share it, But you must attribute it to the original authors (not me):
StackOverFlow
What MIME type if JSON is being returned by a REST API?
提问by ashitaka
My REST API returns JSON.
我的 REST API 返回 JSON。
I'm currently returning text/plain as the MIME type, but it feels funny.
Should I be returning application/x-javascriptor some other type?
我目前将 text/plain 作为 MIME 类型返回，但感觉很有趣。我应该返回application/x-javascript还是其他类型？
The second question is with regard to the HTTP status code for error conditions. If my REST API is returning an error state, I am returning as JSON
第二个问题是关于错误条件的 HTTP 状态代码。如果我的 REST API 返回错误状态，我将作为 JSON 返回
{ result: "fail", errorcode: 1024, errormesg: "That sucked. Try again!" }
Should the HTTP status code remain at 200 OK?
HTTP 状态代码应该保持在200 OK?
回答by Lawrence Dol
The JSONspec suggests application/json, and that seems to be supported by the IETFand IANAregistry.
的JSON规范建议application/json，这似乎是由支持IETF和IANA注册表。
On the second question, I think if the message handling fails in some way you should return a structured and standard error response as a JSON message; only if there is a failure to deliver the message to the backend handler for some reason should you consider an HTTP error code.
关于第二个问题，我认为如果消息处理以某种方式失败，您应该将结构化和标准错误响应作为 JSON 消息返回；只有当由于某种原因无法将消息传递到后端处理程序时，您才应该考虑 HTTP 错误代码。
Update 2014-06-27: The days where clients (browsers) only worked with a 200 response are long past and the prevailing advice for RESTful APIs is to use HTTP response codes appropriate for the response, 2xx for successful responses (e.g. 201 Created for PUT; 204 No Content for DELETE) and 4xx and 5xx for all error conditions, including those from the API itself.
2014年 6 月 27 日更新：客户端（浏览器）只处理 200 个响应的日子已经过去很久了，对 RESTful API 的普遍建议是使用适合响应的 HTTP 响应代码，2xx 用于成功响应（例如 201 Created for PUT; 204 No Content for DELETE) 和 4xx 和 5xx 用于所有错误条件，包括来自 API 本身的错误条件。
回答by inquam
The MIME type of JSON is
JSON 的 MIME 类型是
application/json
application/json
http://www.ietf.org/rfc/rfc4627.txt
http://www.ietf.org/rfc/rfc4627.txt
http://www.iana.org/assignments/media-types/application/
http://www.iana.org/assignments/media-types/application/
More specifically here:
更具体地说，在这里：
回答by Julian Reschke
No, you shouldn't return 200 in an error condition.
不，您不应该在错误情况下返回 200。
It's ok to repeat the status code, or to include a more detailed error code in the response payload.
可以重复状态代码，或者在响应负载中包含更详细的错误代码。
回答by Julian Reschke
I prefer to reply with both an HTTP error status and application specific payload.
我更喜欢同时回复 HTTP 错误状态和应用程序特定的负载。
回答by LukeShu
The proper Content-typeto return is application/json, according to RFC 4627, which also registers the MIME type IANA (and indeed, it shows up on IANA's page). Of course, if you were to write a client, you would want to be more liberal in what you accept, and also accept others such as text/jsonand text/x-json.
根据RFC 4627，Content-type返回的正确值是application/json，它还注册了 MIME 类型 IANA（实际上，它显示在 IANA 的页面上）。当然，如果你要写一个客户端，你会希望在你接受的方面更加自由，并且也接受其他的，比如和。text/jsontext/x-json
Now, if there is an error you should notreturn HTTP 200, that's fundamentally non-RESTful. I know that sometimes there's not an exact match for your error, but choose the closest 4XX (client's fault) or 5XX (server's fault) errors in RFC 2616 Sections 10.4-10.5, and be more precise in the JSON.
现在，如果有错误，你应该不返回HTTP 200，这是从根本上非RESTful。我知道有时您的错误不完全匹配，但在RFC 2616 第 10.4-10.5节中选择最接近的 4XX（客户端错误）或 5XX（服务器错误）错误，并在 JSON 中更精确。
回答by Jason
If by "REST API" you mean that you want to follow a REST architecture then the media type to use is determined by the functionality you want to expose through the REST API. Do you want to be able to create new objects? Query a list of objects? Edit an object? If so, then a good RESTful media type to use might be vnd.collection+json because it defines a hypertext linked interface to manipulate a collection of json objects.
如果“REST API”是指您希望遵循 REST 架构，那么要使用的媒体类型取决于您希望通过 REST API 公开的功能。您是否希望能够创建新对象？查询对象列表？编辑对象？如果是这样，那么一个好的 RESTful 媒体类型可能是 vnd.collection+json，因为它定义了一个超文本链接接口来操作一组 json 对象。
Note: A RESTful API could use the media type application/json, but this media type doesn't have a hypertext linked RESTful interface, so it would be an end point in the state change.
注意：RESTful API 可以使用媒体类型 application/json，但此媒体类型没有超文本链接的 RESTful 接口，因此它将成为状态更改的终点。
It's also completely acceptable to follow a web API architecture, where HTTP RPC calls return application/json objects, and other HTTP RPC calls manipulate those objects, and there is no hypertext link interface for using and navigating the state changes. But this isn't REST.
遵循 Web API 架构也是完全可以接受的，其中 HTTP RPC 调用返回 application/json 对象，其他 HTTP RPC 调用操作这些对象，并且没有用于使用和导航状态更改的超文本链接接口。但这不是 REST。
I like this description of REST (from the creator of REST):
我喜欢 REST 的这个描述（来自 REST 的创建者）：
REST APIS must be hypertext driven
In other words, if the engine of application state (and hence the API) is not being driven by hypertext, then it cannot be RESTful and cannot be a REST API. Period.
换句话说，如果应用程序状态引擎（以及 API）不是由超文本驱动的，那么它就不能是 RESTful，也不能是 REST API。时期。
Also, from the discussion of that post is this example of a RESTful application: Lost Boys's Spam-E REST Application
此外，来自该帖子的讨论是 RESTful 应用程序的这个示例：Lost Boys's Spam-E REST Application
