RESTful API的Mimetypes

Question

http://kenai.com/projects/suncloudapis/pages/Home的Sun Cloud API是RESTful API遵循的一个很好的示例。诚如RESTful原则，当您获取资源时，您只能获得该资源的表示形式。

响应中的Content-Type标头准确告诉您该资源的类型，例如application/vnd.com.sun.cloud.Snapshot + json。 Sun已经向IANA注册了这些mimetypes。

目前这种情况通常如何实用？我见过的大多数API都使用了“application/json”的Content-Type。这告诉你，响应是JSON，但没有更多关于它。你必须在JSON对象中有一些东西，比如“type”属性，才能知道它是什么。我正在设计一个RESTful API（它不会公开，因此我不会注册mimetypes）。我一直在使用RESTEasy，我发现即使我指定了一个完整的mimetype，响应头中的Content-Type也是Accept请求头指定的内容。如果请求默认请求“application/* + json”，则响应头将具有“application/* + json”。我可以通过在响应消失之前更改标题来解决此问题，但是我应该尝试这么做吗？还是应该像请求一样有一个通配符？

还是应该像大多数API一样提供“application/json”似乎要做？

更多的想法后说：

提出这个问题的另一种方式是：我应该使用HTTP的协议，或者我应该用HTTP只是作为传输机制来包装我自己的协议？

要使用HTTP作为协议，响应的实体主体包含请求的对象的表示（或者错误消息对象的表示），“Content-Type”标题包含对象的确切类型，并且“状态”标题包含成功或错误代码。

要使用HTTP作为传输机制，“状态”标题始终设置为200 OK，“Content-Type”类似于“application/json”，并且实体主体包含自身具有的内容一个对象，一个对象类型，一个错误代码和任何你想要的东西。如果你自己的协议是RESTful的，那么整个方案就是RESTful。 （HTTP是RESTful协议，但不是唯一可用的协议。）

您自己的协议对所有传输层都是不透明的。如果你使用HTTP作为协议，所有的传输层都会理解它，并可能做你不想要的东西;比如浏览器会拦截一个“401 Unauthorized”响应，并建立一个登录对话框，即使你想自己处理。

Answer 1

还是应该像大多数API一样提供“application/json”似乎要做？

我不这么认为。

媒体类型是耦合的REST风格的Web应用程序，使用它的客户端之间的唯一点。您的媒体类型的文档是您的API的文档。您的媒体类型是您的客户和您的应用程序之间的合同。消除特定的媒体类型，并消除使REST可用的重要元素。

Sun公司已经注册这些MIME类型与IANA。

找不到any mention of that here。 AFAIK，没有必要实际向IANA注册您的自定义媒体类型。该惯例似乎是使用application/vnd.com.example.app.foo + json的反向域名表示法，它可防止名称空间冲突。如果媒体类型变得稳定和公开，这可能是一个好主意，但没有要求。虽然这可能是错误的。

Answer 2

你会通过指定一个完整的mimetype获得任何价值吗？如果mimetype是application/json，你会对完整的mime类型做什么不同吗？

我的2美分 - 如果API不公开，那么我看不到完整的mimetype的原因。应用程序/ json的MIME类型应该绰绰有余。您已经知道响应正在返回的json类型。如果API最终成为公众，那么担心一个完整的MIME类型......或者让人们弄清楚它。

Answer 3

我用我自己的vnd.mycompany.mymediatype + xml的媒体类型为许多我的表示。在客户端上，我根据返回的表示的媒体类型分派到相应的控制器类。这确实允许服务器控制我的客户端应用程序的行为，以响应用户关注链接。

就我个人而言，如果您希望支持REST客户端，我相信使用application/xml和application/json是最糟糕的选择之一。唯一的例外是客户端只使用下载的代码（如Javascript）来解释数据。