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”响应并建立登录对话框，即使您想自己处理它。
答案 0 :(得分：4)
我为我的许多表示使用自己的vnd.mycompany.mymediatype + xml媒体类型。在客户端上，我根据返回的表示的媒体类型调度到适当的控制器类。这实际上允许服务器控制客户端应用程序的行为，以响应用户关注链接。
就我个人而言，我认为如果您希望支持REST客户端，使用application / xml和application / json是您可以做出的最差选择之一。唯一的例外是当客户端仅使用下载的代码（如Javascript）来解释数据时。
答案 1 :(得分：2)
或者我应该像大多数API一样提供“application / json”吗？
我不这么认为。
媒体类型是RESTful Web应用程序与使用它的客户端之间唯一的耦合点。媒体类型的文档是API的文档。您的媒体类型是您的客户与您的应用程序之间的合同。消除特定媒体类型，消除使REST工作的重要元素。
Sun已将这些mimetypes注册到IANA。
找不到any mention of that here。 AFAIK，无需向IANA实际注册您的自定义媒体类型。该约定似乎是使用application / vnd.com.example.app.foo + json的反向域表示法，它可以防止命名空间冲突。如果您的媒体类型变得稳定和公开，这可能是一个好主意，但没有要求。但是，这可能是错误的。
答案 2 :(得分：0)
通过指定完整的mimetype，您会获得任何价值吗？如果mimetype是application / json，你会对完整的mimetype做什么吗？
我的2美分 - 如果API不会被公开，那么我认为没有理由建立完整的mimetype。应用程序/ json的mimetype应该绰绰有余。您已经知道响应返回的json类型。如果API最终公开，那么担心完整的mimetype ......或者只是让人们弄明白。