我正在开发一个 RESTful API。目前，我正在考虑使用特定于资源的供应商 MIME 类型来传达语义和含义，以及充当客户端和服务器之间的“合同”。
因此，例如 application/vnd.mycompany.person+xml 将意味着有问题的数据是代表一个人的 xml。
我要求将此 API 设为“私有标签”，这意味着经销商可以反过来将 API 提供给他的客户，而他的客户并不知道这是我公司的服务。这样做的方式是我的公司将主 api 托管在一种通用 url，即 www.example.com/api 然后我的公司将使用 CNAME 将我们的域名指向该 url，我们的经销商可以这样做相同。
在内部，所有资源链接都是相对于 API 根的，因此会尊重正在使用的实际 url。
但是，我不想理解/支持任意供应商特定的 MIME 类型，那么上面示例 MIME 类型的“mycompany”部分应该是什么？
HTTP规范说：
不鼓励使用未注册的媒体类型。
我曾经在我的平台中使用“自定义”媒体类型，但这会导致用户代理（浏览器、cURL、wget 等）无法识别内容。
您可以尝试注册您的自定义媒体类型，但是 (A) 这需要一段时间；(B) 用户代理需要很长时间才能识别类型，如果有的话；(C) 你已经表明你不希望公司名称总是出现。
作为“自定义”媒体类型的替代方案，我建议使用媒体类型参数。它们是向媒体类型添加有关内容的补充信息的好方法。
使用参数，您的媒体类型可能是application/xml; mycompany-schema=person或可能只是application/xml; schema=person.
我已经看到了一些框架和教程，它们推荐供应商特定的 mime 类型来“解决”使您的 REST 接口“真正 RESTful”的问题，这仅仅是因为它可以完成，并且以某种方式使其对于 REST 服务来说是合理的。
这种方法的一个问题是，当转向超媒体驱动的 REST 服务的全部目的是改变 API 和服务的模型并改变你如何解决这个问题。偷偷摸摸地为 提供“有效”或允许但不推荐的 HTTP 值Content-Type就像告诉饥饿的委内瑞拉人老鼠是鱼，这样他们就可以在大斋节期间无罪地吃掉它们。如果你只有这些，吃老鼠有什么问题吗？可能不是。但是假装它是一条鱼就让它成为一条鱼吗？当然不是。如果您需要合同驱动的接口，请使用 RPC 或 SOAP 甚至自定义供应商 mime 类型。但不要指着规格说它是休息，因为最后你吃了一只老鼠，每个人都知道，你
第二个问题是，当你偷工减料时，你正在失去超媒体驱动界面的实际回报。你马上就遇到了用户代理的问题，你自己的服务器不得不跳槽或者干脆放弃，因为 mime 类型不熟悉。这一切都是因为您认为您可以同时拥有这两种方式，因为重点不是要通过声称真正的 Rest 服务给您的客户留下深刻印象，或者通过减轻（在某些情况下显然很有价值）合同的额外重量来减轻负载 -驱动交互，它是为了改变你的服务与外部客户端的实际交互方式。
最后，我真的不清楚供应商特定的 mime 类型如何比定义的端点更好地执行合同？所有提到这项技术的网站似乎都对这个选项的存在感到欣慰，坦率地说，他们使用它有点自鸣得意和高兴，就像他们知道它在技术上“顽皮”但它是如此简单和修复一切。它解决了什么问题？在您的情况下，您为什么不简单地将入站person请求/内容转到：
POST /myRestService/people
如果他们有其他请求，是否会转到针对其他数据类型的不同端点？如果你需要一个方法does_something，你不会选择：
GET /myRestService/people/personID_123/does_something
或者
GET /myRestService/people/does_something/personID_123
取决于确切的上下文？
因此，除了疯子之外，我听起来并不刻薄，任何挫折或愤怒根本不是针对您或您的问题，而是针对供应商哑剧类型的“解决方案”以及每个人都为“ Roy Fielding 正式批准并标记为有效的 REST 服务”，显然没有人能够提供一个有效的公共示例，只留下一种紧迫感，立即采取任何需要的捷径，我们可以处理耻辱和稍后当我们真正解决快捷方式所造成的问题时，指指点点。