Generate Golang SDK

[sbliven]

We are using golang for our cli. We've been looking into generating the SciCat data models from the OpenAPI rather than manually coding them. Maybe this could be combined with the python and typescript SDK generation efforts to also generate a Go SDK.

[nitrosx]

@sbliven Do you still need the Golang SDK? If so, have you already generated this SDK locally and do you have the details of the commands?
...or should we just add support for Golang with default options?

Do you know where we should publish the package ( the equivalent of NPM.js for typescript)?

[consolethinks]

I think a golang sdk would be useful. It would guarantee compliance with the scicat backend. It would also probably be ncessary to support the same list of commands that we have in scicat-cli or scicat-cli would have to rewritten with the generated skeleton.

Said commands are as follows:

• ingesting datasets - requires the following interactions with scicat:
  • authentication (eg. GET /users/my/self if using tokens)
  • send metadata for validation - POST /datasets/isValid
  • searching datasets (for existing source folder) - GET /datasets?filter=...
  • create dataset - POST /datasets
  • create origDatablocks - POST /origdatablocks
  • add attachments - POST /datasets/[dataset id]/attachments
  • mark dataset as archivable PATCH /datasets/[dataset id]
• requesting archival (from cache to tape):
  • check for archivable datasets - GET /datasets?filter=...
  • request archival job - POST /jobs
• requesting retrieval (from tape to cache):
  • request retrieval job - POST /jobs
• datasetGetProposal - GET /proposals?filters=...
• datasetCleaner (rarely used) - DELETE /Datasets/[pid]/origdatablocks, DELETE /Datasets/[pid]/attachments, DELETE /Datasets/[pid]
• *datasetPublishData - publishes datasets from the intermediate cache server of the tape archive to the publication server, only uses PATCH /PublishedData/[id] to mark a dataset as published (file transfer happens using tools not related to scicat)
• datasetPublishDataRetrieve - GET /PublishedData/[id], GET /Datasets?filter=isPublished=true&...., it also requests a retrieval job using POST /jobs
• waitForJobFinished - polls a job's status using GET /Jobs/[id]
• *retrieve datasets from cache to local drive - uses GET /datasets?filter= for requesting details about the dataset

*: file transfer between cache and local file storage happens using tools not related to scicat, so I wouldn't personally consider these to be part of a general purpose scicat sdk.

[sbliven]

Thanks for the detailed list, @consolethinks. I guess all of the openapi endpoints would be included as function calls. I'm not sure how much effort it would take to port our existing REST calls to use the SDK.

I think the biggest benefit would be having the DTOs always up to date. Currently we have to detect DTO changes via testing, so it would be nice to have this happen at compile time.

Regarding packaging, Go packages are just pushed as github releases. See Decentralized publishing.