Re: [netmod] adoption poll for yang-versioning-reqs-02

Kent Watsen <kent+ietf@watsen.net> Wed, 20 March 2019 19:24 UTC

Return-Path: <010001699c901a90-fd39b577-918d-4082-b139-b4843f6540cc-000000@amazonses.watsen.net>
X-Original-To: netmod@ietfa.amsl.com
Delivered-To: netmod@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id D7F9E131132 for <netmod@ietfa.amsl.com>; Wed, 20 Mar 2019 12:24:46 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -1.899
X-Spam-Level:
X-Spam-Status: No, score=-1.899 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_NONE=-0.0001] autolearn=ham autolearn_force=no
Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (1024-bit key) header.d=amazonses.com
Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id PhsEtwH4nQFc for <netmod@ietfa.amsl.com>; Wed, 20 Mar 2019 12:24:45 -0700 (PDT)
Received: from a8-88.smtp-out.amazonses.com (a8-88.smtp-out.amazonses.com [54.240.8.88]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 14E081288AB for <netmod@ietf.org>; Wed, 20 Mar 2019 12:24:44 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; q=dns/txt; c=relaxed/simple; s=6gbrjpgwjskckoa6a5zn6fwqkn67xbtw; d=amazonses.com; t=1553109883; h=From:Message-Id:Content-Type:Mime-Version:Subject:Date:In-Reply-To:Cc:To:References:Feedback-ID; bh=xxIo3/x5Xhh7b/oUiNhUbY9hYAfhIJTOhVx090ixveI=; b=EBW9vAnoseIciDc9CbT9ahnv8/DpT9x7xtrOALfC7dKRXrM5RRsa9rRE6hpiQK3v zz5lce4J0/EWe3eYh+rXRoTokqll2+pA8S9w6QniofWMPrzEUIWfYzGIDnychIIgLfq FolWbl5e8wAj98sQm0A9dizzZMzOSijsQj92IPiU=
From: Kent Watsen <kent+ietf@watsen.net>
Message-ID: <010001699c901a90-fd39b577-918d-4082-b139-b4843f6540cc-000000@email.amazonses.com>
Content-Type: multipart/alternative; boundary="Apple-Mail=_B6985765-CD21-4127-A62D-B5BBA01D1729"
Mime-Version: 1.0 (Mac OS X Mail 12.2 \(3445.102.3\))
Date: Wed, 20 Mar 2019 19:24:43 +0000
In-Reply-To: <CABCOCHQX5i1a6zqOSc2ec3YJ=8Ugc6WeN4_uh6YqRq6jKrR1ig@mail.gmail.com>
Cc: "Rob Wilton (rwilton)" <rwilton@cisco.com>, Martin Bjorklund <mbj@tail-f.com>, "netmod@ietf.org" <netmod@ietf.org>
To: Andy Bierman <andy@yumaworks.com>
References: <0100016978b80dcd-31f317a5-443b-400a-98b3-2bfc91841bdc-000000@email.amazonses.com> <20190319.161229.1910835285804688041.mbj@tail-f.com> <aee7d9770a2c4570a3185a1ebeef4c36@XCH-RCD-007.cisco.com> <CABCOCHTsH_wk+MGQwSPA-JZCUiTT38ua-dsnoFgjO=r0U07veA@mail.gmail.com> <8871415dce7343a28afa25faf6080d8c@XCH-RCD-007.cisco.com> <CABCOCHQX5i1a6zqOSc2ec3YJ=8Ugc6WeN4_uh6YqRq6jKrR1ig@mail.gmail.com>
X-Mailer: Apple Mail (2.3445.102.3)
X-SES-Outgoing: 2019.03.20-54.240.8.88
Feedback-ID: 1.us-east-1.DKmIRZFhhsBhtmFMNikgwZUWVrODEw9qVcPhqJEI2DA=:AmazonSES
Archived-At: <https://mailarchive.ietf.org/arch/msg/netmod/7xWQaKEMK5TlsxXdTPqgL7ObeLs>
Subject: Re: [netmod] adoption poll for yang-versioning-reqs-02
X-BeenThere: netmod@ietf.org
X-Mailman-Version: 2.1.29
Precedence: list
List-Id: NETMOD WG list <netmod.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/options/netmod>, <mailto:netmod-request@ietf.org?subject=unsubscribe>
List-Archive: <https://mailarchive.ietf.org/arch/browse/netmod/>
List-Post: <mailto:netmod@ietf.org>
List-Help: <mailto:netmod-request@ietf.org?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/netmod>, <mailto:netmod-request@ietf.org?subject=subscribe>
X-List-Received-Date: Wed, 20 Mar 2019 19:24:47 -0000


> 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.

Kent