search

Open-Network-Models-and-Interfaces-ONMI / TAPI

LF ONMI Transport API Repository (TAPI)
https://github.com/Open-Network-Models-and-Interfaces-ONMI/TAPI/wiki
Apache License 2.0
95 stars 80 forks source link

Ambiguity in the response schema for the same API across different swagger files #365

Closed ganeshrnayak closed 6 months ago

ganeshrnayak commented 5 years ago

There is an ambiguity in the response schema for the same API across different swagger(OAS/*.yaml) files.

For the same URL, there are different response schema published the in the swagger files :

ex : for the same API /data/context/topology={uuid}/node={node-uuid}/owned-node-edge-point={owned-node-edge-point-uuid}/ tapi-topology@2018-08-31.yaml has the response schema : $ref: "#/definitions/tapi.topology.NodeEdgePoint"

However, tapi-connectivity@2018-08-31.yaml has the response schema : $ref: "#/definitions/tapi.topology.node.OwnedNodeEdgePoint"

There are a few more such ambiguities observed, can be seen in the attached files : photonic-conectivity-service_vs_connectivity-connectivity-service topology-owned-nep_vs_connectivity-owned-nep connectivity-cep_vs_photonic-cep connectivity-sip_vs_photonic-sip

cc : @amazzini

bartoszm commented 5 years ago

@ganeshrnayak could you please give me some insights on how do you generate the swagger? e.g. is it always generated from the same set of yang files? how to reproduce what you do observe

pedrofsamaral commented 5 years ago

Hello,

this seems to happen because the OAS files are generated individually, meaning that for the example the connectivity model augments the node/owned-node-edge-point with the cep-list resulting that on a different (extended) object in connectivity OAS to address the difference to the "base" node-edge-point. I would say that the individual OAS files are still relevant and useful for who wants to implement only a single service (e.g. only topology) but I would consider to generate also a OAS with all the services in it.

Maybe the way to go for the example would be to use only connectivity OAS since it imports and extends topology model. This should apply to all extensions, i.e. to use as reference the OAS of the model that extends and includes the "base" one. The only issue with this, and that's why I suggest to have a "total" OAS with all models is for the case where two models extend the same one with different things and we need to have as reference both OAS.

I hope this clarifies the issue reported.

Also, it would be helpful as guidance to have the exact command that was used to generate the published OAS files from the published YANG for the ones that want to generate their own combinations of T-API models on a single OAS.

amazzini commented 6 months ago

This issue has been closed due to the lack of activity for more than one year. Please reopen it if follow up is necessary.