用于RESTful API的Mimetypes

http://kenai.com/projects/suncloudapis/pages/Home上的Sun Cloud API 是RESTful API的一个很好的示例.忠实于RESTful原则,当您获取资源时,您获得的资源不会少于或少于该资源的表示.

响应中的Content-Type标头可以准确地告诉您该资源的类型,例如application/vnd.com.sun.cloud.Snapshot + json.Sun已将这些mimetypes注册到IANA.

目前这一般有多实用？我见过的大多数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仅用作传输机制,"Status"标头始终设置为200 OK,"Content-Type"是通用的,如"application/json",实体主体包含自身具有对象的内容,对象类型,错误代码以及您想要的任何其他内容.如果您自己的协议是RESTful,那么整个方案就是RESTful.(HTTP是RESTful协议,但不是唯一可能的协议.)

您自己的协议对所有传输层都是不透明的.如果您使用HTTP作为协议,所有传输层都将理解它并可能做您不想要的事情; 例如,浏览器将拦截"401 Unauthorized"响应并建立登录对话框,即使您想自己处理它.