On Wed, Mar 20, 2019 at 12:24 PM Kent Watsen <[email protected]> wrote:
> > > I don't think the versioning data nodes is a good idea. > I have seen entire REST APIs be versioned, but not individual parameters > within the API. > > > FWIW, I have seen individual resources versioned within a REST API, in > lieu of a version number in the beginning of the URL. The REST API > presented resources for versioned "objects", each having a distinct media > type for content negotiation > (e.g., application/vnd.<company>.<object>+[xml/json];v=2). > > Clients asked for what they could support (including older versions, in > case the server didn't support the latest). Server's up/down-converted > objects through a chain of converters. Each release only had converters > to/from the previous release, but only for the objects that changed. > > It worked well. The API was stable. Clients did not have to support all > the new object versions in one go. Incremental transition was common. > > This is much simpler because the REST APIs are like RPC operations in YANG -- they do not interact with each other. In fact, it is impossible in YANG to have the XPath/leafref cross-references in 1 RPC access another RPC. It is easy to support many revisions of an RPC operation. Not so easy for the contents of a YANG datastore. Changing the data type, config-stmt, or data definition type are drastic changes that will affect cross-references. These might be the only NBC changes that really matter. Anything else you could call a bugfix and it would be better to fix than replace (e.g., add/modify/delete must/when/mandatory) I agree with Martin that NBC changes cannot be allowed and a new definition is required to replace the broken one. Perhaps Lada is right that the YANG update rules are too strict. There are many things that could be considered a bugfix that are not allowed. But I don't think a version string format fixes any of the hard problems. More YANG statements, extensions, and annotations (in NETCONF) are needed to really address the problem, (E.g., where is the 301 Redirect for NETCONF/YANG?) Kent > > Andy
_______________________________________________ netmod mailing list [email protected] https://www.ietf.org/mailman/listinfo/netmod
