Create the API definitions in the / of each Application

[felipevicens]

I would like to have in the / of the API the API structure.

Something like this: http://sp.int.sonata-nfv.eu:4002/catalogues/

[shuaibsiddiqui]

From @jbonnet : suggestion: instead of "/catalogues/packages/id/{_id}" just "/catalogues/packages/{id}" or even "/catalogues/packages/{uuid}" and instead of "/catalogues/packages/vendor/{package_group}/name/{package_name}/version/{package_version}" why not a more general and standard "/catalogues/packages?vendor={package_group}&name={package_name}&version={package_version}"

[dang03]

The problem of: /catalogues/packages/{uuid} Everything that comes after /packages/ will be understood as a id, and this doesn't enable to use any other query field but id, e.g. /catalogues/packages/vendor/{package_group} would result in an error.

Specifying a field /id/{_id}, /vendor/{package_group}, /name/{package_name}, etc. is just a matter of classification of fields, pairing (key=value --> /key/{value}) and simplicity. For this reason we can have a hierarchy of methods for each query-able attribute like this:

GET methods: 'uri' => '/catalogues/',

'uri' => '/catalogues/network-services', 'uri' => '/catalogues/network-services/id/{id}', 'uri' => '/catalogues/network-services/name/{name}', 'uri' => '/catalogues/network-services/name/{name}/version/{version}', 'uri' => '/catalogues/network-services/name/{name}/last', 'uri' => '/catalogues/network-services/vendor/{vendor}/name/{name}/version/{version}',

'uri' => '/catalogues/vnfs', 'uri' => '/catalogues/vnfs/id/{id}', 'uri' => '/catalogues/vnfs/name/{name}', 'uri' => '/catalogues/vnfs/name/{name}/last', 'uri' => '/catalogues/vnfs/name/{name}/version/{version}', 'uri' => '/catalogues/vnfs/vendor/{vendor}/name/{name}/version/{version}'

[jbonnet]

Well... People used to work with REST will be expecting from our API something like

/catalogues/network-services
/catalogues/network-services/{uuid}
/catalogues/network-services?param1=value1&param2=value2...

It's what everyone uses, it's simpler and easier to learn (to use our API). What's the value we're adding with such a change?

[dang03]

I do not agree with that of "It's what everyone uses"... If you check, for example, Opendaylight REST API, works very similar, the same for ASP.NET APIs, these REST APIs follow this approach e.g. /api/books/{id}/details... etc. But it is OK, assuming that you need your proposed API style for the Gatekeeper, for any reason, I will consider it, and evaluate the needed effort for these changes.

[jbonnet]

@dang03 The example you give (/api/books/{id}/details) is ok: it means you have a book resource, select one through it's id, and then you want the details resources connected to it. Nothing wrong with that, you have no .../id/{id}. See what I mean? While when doing things like .../catalogues/vnfs/vendor/{vendor}/name/{name}/version/{version}, your implying hierarchy relations between vendor, name and version, which is not true: vendor, name and version are just attributes of the vnfsresource.

Got it? ;-)

[dang03]

Yes, I see your point with the hierarchy relations. I'm talking with Felipe to see if we can change the routes, thankfully it might not require much effort to modify the code.