| || TAPI REST-RPC alignment for v2.2-RC2|
- It was acknowledged that TAPI UML Operations that specify equivalent CRUD operations explicitly are in general redundant and should be removed in Tapi 3.0 since the same can be achieved by updating the code/data-schema generation tools to properly generate the CRUD operations from the class information model and attribute's read/write property.
- Equivalent RPC parameters and REST/Object attributes should use same label/name.
- Create/Post operations: UUID for create/post operations - Since RESTConf requires the client/requestor to provide the key attributes (uuid in case of TAPI) in the create operations for the configurable lists, agreed that all TAPI create/post operations will require the TAPI client to provide an UUID parameter. Will return the created object
- Delete operations should not return any output (deleted object instance)
- Update operations - case of strictly composed children classes (e.g. ConnService has strictly composed children CSEPs) - update operation on the parent (ConnService) takes in a list of the child object instances (CSEP list) and the the implementation has to figure out if a child instance (CSEP instance) already exists and if so has to figure out the delta to update the child (CSEP) or absence implies that child instance has to be removed. In some cases, this was deemed confusing and so we provide explicit add/delete/update operations for the strictly composed children (e.g. Create/Delete/Update CSEP). So make this a consistent policy? Agreement: NO
- Get RPCs - for strictly composed children - present in some case, not present in other cases. Agreed to consistently add (on best-effort basis) any additional get() for strictly composed children (mostly redundant) operations as removing all of these operations would be considered backward-incompatible (major version change).
- Get All RPCs - for strictly composed children - For now, no additional GetAll RPCs to be added for strictly composed children as these are deemed to be redundant in general.
- GetIds RPCs - For now, will not implement this in 2.2. In 3.0, we will implement find/search query based API to replace GetAll where it is possible to filter both the number of returned objects and the object attributes/fields.