REST 媒体类型爆炸 [英] REST Media type explosion

问题描述

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

In my attempt to redesign an existing application using REST architectural style, I came across a problem which I would like to term as "Mediatype Explosion". However, I am not sure if this is really a problem or an inherent benefit of REST. To explain what I mean, take the following example

我们的应用程序的一小部分看起来像:

One tiny part of our application looks like:

collection-of-collections->collections-of-items->items

collection-of-collections->collections-of-items->items

即顶层是一个集合的集合，这些集合中的每一个又是一个项目的集合.

i.e the top level is a collection of collections and each of these collection is again a collection of items.

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

Also, each item has 8 attributes which can be read and written individually. Trying to expose the above hierarchy as RESTful resources leaves me with the following media types:

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

此外，由于每个项目有 8 个可以单独读写的属性，因此会产生另外 8 种媒体类型.例如项目的值"属性的一种这样的媒体类型是:

Further more, since each item has 8 attributes which can be read and written to individually, it will result in another 8 media types. e.g. one such media type for "value" attribute of an item would be:

application/vnd.mycompany.item_value+xml

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

As I mentioned earlier, this is just a tiny part of our application and I expect several different collections and items that needs to be exposed in this way.

我的问题是:

1. 拥有如此众多的媒体类型，我是否做错了什么?
2. 避免这种媒体类型爆炸的替代设计方法是什么?

我也知道上面的设计是高度细化的，尤其是暴露了项目的各个属性，并为每个属性设置了单独的媒体类型.但是，使其粗糙意味着我最终将通过网络传输不必要的数据，而实际上客户端只需要读取或写入项目的单个属性.您将如何处理这样的设计问题?

I am also aware that the design above is highly granular, especially exposing individual attributes of the item and having separate media types for each them. However, making it coarse means I will end up transferring unnecessary data over the wire when in reality the client only needs to read or write a single attribute of an item. How would you approach such a design issue?

推荐答案

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

One approach that would reduce the number of media types required is to use a media type defined to hold lists of other media-types. This could be used for all of your collections. Generally lists tend to have a consistent set of behavior. You could roll your own vnd.mycompany.resourcelist or you could reuse something like an Atom collection.

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

With regards to the specific resource representations like vnd.mycompany.item, what you can do depends a whole lot on the characteristics of your client. Is it in a browser? can you do code-download? Is your client a rich UI, or is it a data processing client?

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

If the client is going to do specific data processing then you pretty much need to stick with the precise media types and you may end up with a large number of them. But look on the bright side, you will have less media-types than you would have namespaces if you were using SOAP!

请记住，媒体类型是您的合同，如果您的应用程序需要与客户端定义大量合同，那么就这样吧.

Remember, the media-type is your contract, if your application needs to define lots of contracts with the client, then so be it.

但是，我不会定义合约来交换单个属性值.如果您觉得有必要这样做，那么您在设计中做错了其他事情.分布式界面设计需要有粗犷的对话，而不是喋喋不休的对话.

However, I would not go as far as defining contracts to exchange single attribute values. If you feel the need to do that, then you are doing something else wrong in your design. Distributed interface design needs to have chunky conversations, not chatty ones.

这篇关于REST 媒体类型爆炸的文章就介绍到这了，希望我们推荐的答案对大家有所帮助，也希望大家多多支持IT屋！