Question

我们目前有4种内容类型可能包含在投放中。在大约8-12个月内，我们可能会有另外2-4种内容类型。我现在正在开发一个公共REST api，并想知道我是否可以用这样的方式编写api，以便将来添加不需要版本冲突？

目前我们认为delivery会返回类似这样的json结果：

{
    "dateDelivered": "2016-01-01",
    "clientId": "000001",
    "contentCounts" : {
         "total" : 100,
         "articles": 75,
         "slideshows": 25
         ... // other content types as we add them
    }
    "content" : {
         "articles" : "http://api.example.com/v0/deliveries/1234/content/articles",
         "slideshows" : "http://api.example.com/v0/deliveries/1234/content/slideshows",
         ... // other content types as we add them
     }
}

将contentCounts和content定义为具有每种可用内容类型的可选属性的对象。我想我可以将其定义为每种内容类型的对象数组，但我不知道这会如何改变任何内容。

如果将来结果对象看起来更像是这样的话，有什么理由是一个突破性的变化：

{
    "dateDelivered": "2016-01-01",
    "clientId": "000001",
    "contentCounts" : {
         "total" : 150,
         "articles": 75,
         "slideshows": 25,
         "events": 25,
         "videos": 25
    }
    "content" : {
         "articles" : "http://api.example.com/v0/deliveries/1234/content/articles",
         "slideshows" : "http://api.example.com/v0/deliveries/1234/content/slideshows",
         "events" : "http://api.example.com/v0/deliveries/1234/content/events",
         "videos" : "http://api.example.com/v0/deliveries/1234/content/videos"
     }
}

Answer 1

突破变化是一个相对的概念。它打破了不考虑这些更改的客户端代码。在您的情况下，如果REST API的客户端硬编码了内容类型，那么他将需要更改其代码以考虑新的内容类型。

从这个意义上讲，他的代码被破坏了，因为它无法处理所有代码。在另一种意义上，他的代码没有被破坏，因为只要你不删除内容类型，他的代码将继续适用于它支持的内容类型。

如果客户端代码足够聪明，可以遍历属性并对变更保持灵活性，那就没问题了。

无论如何，如果您打算更改模型，您应该提及它。无论是添加，删除还是重命名这些内容类型，如果客户端知道它，他都可以编写一个成功使用REST API的客户端。在这种情况下，NO，它不会是一个突破性的变化，因为它具有动态结构（内容类型可以变化），但是以结构化的方式。

我可以在不进行重大更改的情况下添加新的REST属性吗？

1 个答案: