我正在开发一个RESTful API。目前，我正在考虑使用特定于资源的供应商MIME类型来传达语义和含义，以及充当客户端和服务器之间的“契约”。
例如，application / vnd.mycompany.person + xml意味着有问题的数据是代表一个人的xml。
我要求将此API设为“私有标记”，这意味着经销商可以反过来向其客户提供API，而不会让客户知道这是我公司的服务。这样做的方式是我的公司将主要api托管在某种通用URL上，即www.example.com/api然后我的公司会使用CNAME将我们的域名指向该URL，我们的经销商可以做同样的。
在内部，所有资源链接都是API根相对的，因此会尊重正在使用的实际网址。
但是，我不想理解/支持任意供应商特定的MIME类型，那么上面示例MIME类型的“mycompany”部分应该是什么？
答案 0 :(得分：4)
HTTP规范says：
不鼓励使用未注册的媒体类型。
我曾经在我的平台中使用“自定义”媒体类型，但它导致用户代理（浏览器，cURL，wget等）无法识别内容的问题。
您可以尝试注册自定义媒体类型，但（A）需要一段时间; （B）在用户代理识别类型之前需要很长时间，如果有的话; （C）您已经表明您不希望公司名称始终存在。
作为“自定义”媒体类型的替代方案，我建议使用媒体类型参数;他们是向媒体类型添加内容补充信息的有福方式。
使用参数，您的媒体类型可以是application/xml; mycompany-schema=person，也可以只是application/xml; schema=person。
答案 1 :(得分：2)
我已经看到了一些框架和教程，它们推荐供应商特定的mime类型来“解决”问题，使您的REST界面“真正RESTful”，因为它可以完成，并以某种方式使其成为REST服务的犹太人。
这种方法的一个问题是，当转换到超媒体驱动的REST服务的整个过程就是改变API的模型时，本质上是一种黑客或欺骗手段，以“按照你想要的方式工作”。服务并改变您解决问题的方式。偷走Content-Type的“有效”或允许但不推荐的HTTP值就像告诉饥饿的委内瑞拉人说老鼠是鱼，所以他们可以在四旬期间无罪地吃它们。吃大鼠有什么不妥的吗？可能不是。但是假装它的鱼却成了鱼吗？当然不是。如果您需要一个契约驱动的接口，请使用RPC或SOAP，甚至是自定义供应商的mime-type。但是不要指出规范并说它是休息，因为最后你吃了一只老鼠，每个人都知道它，而你只是骗你自己。
第二个问题是，当你偷工减料时，你正在失去超媒体驱动界面的实际奖励。你立即遇到问题，用户代理和你自己的服务器不得不跳过篮球或者只是因为mime类型不熟悉而放弃。所有这些都是因为你认为你可以通过两种方式获得真正的休息服务，或者通过减少（在某些情况下显然有价值）合同的额外重量来减轻负担 - 推动互动，改变服务实际与外部客户的互动方式。
最后，我真的不清楚供应商特定的mime类型如何比定义的端点更好地实施合同？所有提到这种技术的网站似乎只是松了一口气，这个选项存在，坦率地说，他们使用它有点自负和高兴，就像他们知道它在技术上“顽皮”但它只是如此容易和修复一切。它解决了什么？在您的情况下，为什么您不能简单地将您的入站person请求/内容转到：
POST /myRestService/people
如果他们有其他请求，请将其转到另一个针对该其他数据类型的端点吗？如果你需要一个方法does_something，你不会选择：
GET /myRestService/people/personID_123/does_something
或
GET /myRestService/people/does_something/personID_123
取决于具体情况？
就这样，我听起来并不是疯狂的，任何挫折或愤怒根本不是针对你或你的问题，而是针对供应商mime-type的“解决方案”和痴迷每个人都为“罗伊菲尔丁正式批准和盖章而开发 作为有效的REST服务“显然没有人能够提供一个有效的公共示例，只留下一种紧迫感，立即采用它，采取任何需要的快捷方式，我们可以在我们实际修复时处理羞耻和指责捷径的问题。