rest - REST媒体类型爆炸

在尝试使用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

如前所述，这只是我们应用程序的一小部分，我希望需要以这种方式公开几个不同的集合和项目。

我的问题是:

通过使用大量的媒体类型，我做错什么了吗？

有什么替代的设计方法来避免媒体类型的爆炸式增长？

我还知道，上面的设计是非常精细的，特别是公开了项目的各个属性，并为每个属性设置了单独的媒体类型。但是，粗略地表示，当客户实际上只需要读取或写入项目的单个属性时，我最终将通过电线传输不必要的数据。您将如何处理这样的设计问题？

最佳答案

一种减少所需媒体类型数量的方法是使用定义为保存其他媒体类型列表的媒体类型。这可以用于所有收藏。通常，列表倾向于具有一致的行为集。
您可以滚动自己的vnd.mycompany.resourcelist，也可以重用Atom collection之类的东西。

对于诸如vnd.mycompany.item之类的特定资源表示形式，您可以做的事情很大程度上取决于客户的特征。在浏览器中吗？可以下载代码吗？您的客户端是功能丰富的UI，还是数据处理客户端？

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

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

但是，对于定义交换单个属性值的契约(Contract)，我不会走得更远。如果您认为需要这样做，那么您在设计中就犯了其他错误。分布式接口(interface)设计需要 session 很短，而不是健谈。

关于rest - REST媒体类型爆炸，我们在Stack Overflow上找到一个类似的问题：https://stackoverflow.com/questions/880881/