[core] #415 (interfaces): Linked Batched post usage, persistency and version need for interfaces

"core issue tracker" <trac+core@zinfandel.tools.ietf.org> Fri, 15 July 2016 10:23 UTC

MIME-Version: 1.0
Content-Type: text/plain; charset="utf-8"
Content-Transfer-Encoding: 7bit
From: core issue tracker <trac+core@zinfandel.tools.ietf.org>
Precedence: bulk
Auto-Submitted: auto-generated
To: draft-ietf-core-interfaces@tools.ietf.org, lauri.piikivi@arm.com
Date: Fri, 15 Jul 2016 10:23:29 -0000
Message-ID: <061.bb9885835d474fbcc690496598378041@trac.tools.ietf.org>
Resent-To: draft-ietf-core-interfaces@ietf.org
Resent-Message-Id: <20160715102345.3658112DC29@ietfa.amsl.com>
Resent-Date: Fri, 15 Jul 2016 03:23:45 -0700
Resent-From: trac+core@trac.tools.ietf.org
Archived-At: <https://mailarchive.ietf.org/arch/msg/core/udaRWfYUZjpXLiiT9loBK6EynsU>
Cc: core@ietf.org
Subject: [core] #415 (interfaces): Linked Batched post usage, persistency and version need for interfaces
Reply-To: trac+core@zinfandel.tools.ietf.org

#415: Linked Batched post usage, persistency and version need for interfaces

 Hi,

 Reading the draft, some comments below.

 == POST usage ==
 In chapter 5.3 for the linked batch, POST is used as modification and
 creation of the list. POST is usually understood as  creation (for CRUD
 operations). We have PATCH for modify operation. I recommend to use PATCH
 for modification operations.
  - POST creates
  - PUT replaces
  - PATCH modifies (appends)
  - DELETE removes

 == Linked Batch as persistent resource or transient configuration ==
 There may be servers that create a persistent linked batch. They should be
 able to return the location, the new resource, to client. Even for
 transient (RAM storage linked batch), location usage could clarify the
 situations with server reset. The server is often in an embedded, maybe
 wireless, device and reset operations are common. If a linked batch is
 created, and server resets, a modification later on can actually be a
 creation operation, especially if POST is used for both creation and
 modification.

 Server should return a new resource id in location header for linked batch
 creation. Later operations use  that resource URI for modifications and
 delete. If the resource is lost (RAM reset), a not found error is
 returned.  It may be not too far in future that an embedded server has
 different linked batch for different clients.

 Persistent linked batch is reported to the RD or client well-known query
 as a resource in the server.

 Should we have different interface type or identification for persistent
 linked batch?

 == Interface Version ==
 The chapter on function set (ch 6) talks about the need for versioning. It
 is not clear to me how the version would work? Do we need version in the
 interface information? Web/REST apis are truly fast evolving, and a
 version information might be needed for a client to understand what
 version of an interface is in use. The version information might be in the
 interface name (v1, v2 in the end) or in link parameter even?
 If linked batch returns a new resource, should we have the version
 information as link parameter? Creation makes version 1, modifications
 increase the version number?

-- 
-------------------------+-------------------------------------------------
 Reporter:               |      Owner:  draft-ietf-core-
  lauri.piikivi@arm.com  |  interfaces@tools.ietf.org
     Type:  protocol     |     Status:  new
  enhancement            |  Milestone:
 Priority:  minor        |    Version:
Component:  interfaces   |   Keywords:
 Severity:  -            |
-------------------------+-------------------------------------------------

Ticket URL: <https://tools.ietf.org/wg/core/trac/ticket/415>
core <https://tools.ietf.org/core/>

[core] #415 (interfaces): Linked Batched post usa… core issue tracker