Get Package file from SP about son-tests

[jbonnet]

@dang03
The Gatekeeper is ready, but there are still compromises with the Catalogues I'd like to see removed, like:

1. the package file name: why filename.son? I know we've discussed this sometime ago... what have I forgotten?
2. HTTP header application/json should return a JSON description of the package file, while application/zip should return the file, for the .../catalogue/son-packages/:uuid, no? Both calls are currently returning binary data
3. from the GK API's point of view, the call to get the file is .../packages/:uuid/download, i.e., there's no 'special' (like in son-pakages`) endpoint for downloading files

[dang03]

@jbonnet
Addressing your points:

1. The package file is indeed a zip file, however, long time ago it was stated (I don't remember well) that SONATA packages would use .son extension. No problem in this, the Catalogue support any kind of file extension, as long as you provide a filename.

2. This was a bug. Now, with the last son-catalogue-repos commit (still pending to merge) you will be able to get the package file meta-data using application/json header or the package file itself using application/zip header for the .../catalogues/api/v2/son-packages/:uuid.
   Note: This only works on API v2!! .../catalogues/api/v2/...

3. That's fine to have one API dedicated to Packages (descriptors and files) in the GK. However in the Catalogue it is managed separately as a descriptor and a file are stored in different "catalogues", so different APIs.

[jbonnet]

Top, @dang03! 1. ok 2. ok, great, I’ll have to finish the GK API now; 3. ok, no problem, the Catalogue may keep its separate APIs, the SDK, BSS or GUI will see only one; I think it’s simpler this way.

…

On 22 Mar 2017, at 11:59, Daniel ***@***.***> wrote: @jbonnet <https://github.com/jbonnet> Addressing your points: The package file is indeed a zip file, however, long time ago it was stated (I don't remember well) that SONATA packages would use .son extension. No problem in this, the Catalogue support any kind of file extension, as long as you provide a filename. This was a bug. Now, with the last son-catalogue-repos commit (still pending to merge) you will be able to get the package file meta-data using application/json header or the package file itself using application/zip header for the .../catalogue/son-packages/:uuid. That's fine to have one API dedicated to Packages (descriptors and files) in the GK. However in the Catalogue it is managed separately as a descriptor and a file are stored in different "catalogues", so different APIs. — You are receiving this because you were mentioned. Reply to this email directly, view it on GitHub <#245 (comment)>, or mute the thread <https://github.com/notifications/unsubscribe-auth/AAAuQz8O-B5aK3c-x_5b32-y8hgGNV1Bks5roQ0zgaJpZM4Mdnd8>.

[jbonnet]

BTW, @dang03, @felipevicens The integration test for the package download will have to be uncommented and fixed, I can do it later...

…

On 22 Mar 2017, at 12:05, José Bonnet ***@***.***> wrote: Top, @dang03! 1. ok 2. ok, great, I’ll have to finish the GK API now; 3. ok, no problem, the Catalogue may keep its separate APIs, the SDK, BSS or GUI will see only one; I think it’s simpler this way. > On 22 Mar 2017, at 11:59, Daniel ***@***.*** ***@***.***>> wrote: > > @jbonnet <https://github.com/jbonnet> > Addressing your points: > > The package file is indeed a zip file, however, long time ago it was stated (I don't remember well) that SONATA packages would use .son extension. No problem in this, the Catalogue support any kind of file extension, as long as you provide a filename. > > This was a bug. Now, with the last son-catalogue-repos commit (still pending to merge) you will be able to get the package file meta-data using application/json header or the package file itself using application/zip header for the .../catalogue/son-packages/:uuid. > > That's fine to have one API dedicated to Packages (descriptors and files) in the GK. However in the Catalogue it is managed separately as a descriptor and a file are stored in different "catalogues", so different APIs. > > — > You are receiving this because you were mentioned. > Reply to this email directly, view it on GitHub <#245 (comment)>, or mute the thread <https://github.com/notifications/unsubscribe-auth/AAAuQz8O-B5aK3c-x_5b32-y8hgGNV1Bks5roQ0zgaJpZM4Mdnd8>. >

[dang03]

@jbonnet
The integration test for the package download Jenkins <-> GK <-> Catalogue is now enabled and working correctly.