6

我正在开发一个 RESTful API。目前,我正在考虑使用特定于资源的供应商 MIME 类型来传达语义和含义,以及充当客户端和服务器之间的“合同”。

因此,例如 application/vnd.mycompany.person+xml 将意味着有问题的数据是代表一个人的 xml。

我要求将此 API 设为“私有标签”,这意味着经销商可以反过来将 API 提供给他的客户,而他的客户并不知道这是我公司的服务。这样做的方式是我的公司将主 api 托管在一种通用 url,即 www.example.com/api 然后我的公司将使用 CNAME 将我们的域名指向该 url,我们的经销商可以这样做相同。

在内部,所有资源链接都是相对于 API 根的,因此会尊重正在使用的实际 url。

但是,我不想理解/支持任意供应商特定的 MIME 类型,那么上面示例 MIME 类型的“mycompany”部分应该是什么?

4

2 回答 2

4

HTTP规范

不鼓励使用未注册的媒体类型。

我曾经在我的平台中使用“自定义”媒体类型,但这会导致用户代理(浏览器、cURL、wget 等)无法识别内容。

您可以尝试注册您的自定义媒体类型,但是 (A) 这需要一段时间;(B) 用户代理需要很长时间才能识别类型,如果有的话;(C) 你已经表明你不希望公司名称总是出现。

作为“自定义”媒体类型的替代方案,我建议使用媒体类型参数。它们是向媒体类型添加有关内容的补充信息的好方法。

使用参数,您的媒体类型可能是application/xml; mycompany-schema=person或可能只是application/xml; schema=person.

于 2011-08-02T23:27:31.253 回答
2

我已经看到了一些框架和教程,它们推荐供应商特定的 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 服务”,显然没有人能够提供一个有效的公共示例,只留下一种紧迫感,立即采取任何需要的捷径,我们可以处理耻辱和稍后当我们真正解决快捷方式所造成的问题时,指指点点。

于 2013-09-17T13:04:45.137 回答