Opened 6 years ago

#415 new protocol enhancement

Linked Batched post usage, persistency and version need for interfaces

Reported by: lauri.piikivi@… Owned by: draft-ietf-core-interfaces@…
Priority: minor Milestone:
Component: interfaces Version:
Severity: - Keywords:
Cc:

Description

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?

Change History (0)

Note: See TracTickets for help on using tickets.