REST 媒体类型爆炸

Question

在尝试使用 REST 架构风格重新设计现有应用程序时，我遇到了一个问题，我想将其称为“媒体类型爆炸”。然而，我不确定这是否真的是一个问题，还是 REST 的固有好处。为了解释我的意思，请看下面的例子

我们的应用程序的一小部分如下所示:

集合的集合->项目的集合->项目

即顶层是集合的集合，并且每个集合又是项目的集合。

此外，每个项目都有 8 个可以单独读写的属性。尝试将上述层次结构公开为 RESTful 资源，我得到以下媒体类型:

application/vnd.mycompany.collection-of-collections+xml
application/vnd.mycompany.collection-of-items+xml
application/vnd.mycompany.item+xml

此外，由于每个项目有 8 个可以单独读写的属性，因此将产生另外 8 种媒体类型。例如项目“值”属性的一种此类媒体类型是:

application/vnd.mycompany.item_value+xml

正如我之前提到的，这只是我们应用程序的一小部分，我预计需要以这种方式公开几个不同的集合和项目。

我的问题是:

1. 拥有如此大量的媒体类型是不是我做错了什么？
2. 避免媒体类型爆炸的替代设计方法是什么？

我还知道上面的设计是高度精细的，特别是公开了项目的各个属性并为每个属性提供了单独的媒体类型。然而，使其变得粗糙意味着我最终会通过线路传输不必要的数据，而实际上客户端只需要读取或写入项目的单个属性。您将如何处理这样的设计问题？

Answer 1

减少所需媒体类型数量的一种方法是使用定义为保存其他媒体类型列表的媒体类型。这可以用于您的所有收藏。一般来说，列表往往具有一组一致的行为。您可以推出自己的 vnd.mycompany.resourcelist，也可以重复使用类似 Atom collection 的内容。 .

对于像 vnd.mycompany.item 这样的特定资源表示，您可以做什么很大程度上取决于您的客户端的特征。是在浏览器中吗？你可以下载代码吗？您的客户端是一个丰富的 UI，还是一个数据处理客户端？

如果客户端要进行特定的数据处理，那么您非常需要坚持使用精确的媒体类型，并且最终可能会得到大量的媒体类型。但从好的方面来看，如果您使用 SOAP，您所拥有的媒体类型将比命名空间少!

请记住，媒体类型是您的契约(Contract)，如果您的应用程序需要与客户端定义大量契约(Contract)，那就这样吧。

但是，我不会定义合约来交换单个属性值。如果您觉得有必要这样做，那么您在设计中就犯了其他错误。分布式界面设计需要有丰富的对话，而不是闲聊。