Long discussion on the pending decision whether YANG list object retrieval will be enforced or not, see also 2020-12-15 TAPI Meeting Notes.
- Ramon Casellas points out that in Restconf environment the GET on lists is a common, expected capability.
- Karthik Sethuraman clarifies that if we allow the
- GET tapi-common:context/service-interface-point/ then becomes necessary to add also the
- GET /tapi-common:context/service-interface-point?fields=uuid which result is essentially same as
- GET /tapi-common:context?fields=service-interface-point(uuid)
- With reference to YANG to OAS tool does not generate GET with potentially multiple replies (#497), Karthik Sethuraman clarifies that these APIs are not generated by choice, because:
- In case of XML encoding, a dedicated container is necessary for the multiple replies (GET to retrieve multiple elements are allowed if the encoding is based on JSON).
- Possible performance issues, because the whole subtree content is systematically replied.
- Same result is obtained by the GET on the parent node, e.g. instead of retrieving the list of NEPs, retrieve the Node with filter on node-edge-point UUID.
- Andrea Mazzini as a general rule, a Reference Implementation shall avoid any unnecessary variation, to facilitate interoperability. The RIA is anyway not forbidding the implementation of GET list.
- Ramon Casellas recalls that the GET list is anyway very common.
Eventually agreed to remove from RIA Table 3: Minimum subset required of TAPI RESTCONF Data API the following GET APIs:
- Ramon Casellasto add a clarification note in the RIA, explaining the rationale of this choice.