Implement access methods

[uniqueg]

This is a meta-issue to help keep track on what access methods are still left to implement. Please don't close this issue until all boxes are checked (note that additional boxes may be added later).

To implement one of the methods, open a specific issue for the access method you would like to implement (if it doesn't already exist), assign yourself to that issue, implement it (look at #5, #6 and #7 for examples), implement tests, update the README.md, file a PR and mention the specific issue in the PR description. Then, once done, tick off the corresponding item in the lists below.

TRS access methods to implement:

• [x] .get_service_info() for GET /service-info (#38 / #40)
• [x] .get_tool_classes() for GET /toolClasses (#11)
• [x] .get_tools() for GET /tools (#15 / #16)
• [x] .get_tool() for GET /tools/{id} (#12)
• [x] .get_versions() for GET /tools/{id}/versions (#17 / #19)
• [x] .get_version() for GET /tools/{id}/versions/{version_id} (#18 / #20)
• [x] .get_containerfiles() for GET /tools/{id}/versions/{version_id}/containerfile (#41 / #43)
• [x] .get_descriptor() for GET /tools/{id}/versions/{version_id}/{type}/descriptor (#5)
• [x] .get_descriptor_by_path() for GET /tools/{id}/versions/{version_id}/{type}/descriptor/{relative_path} (#7)
• [x] .get_files() for GET /tools/{id}/versions/{version_id}/{type}/files (#6)
• [x] .get_tests() for GET /tools/{id}/versions/{version_id}/{type}/tests (#42 / 44)

TRS-Filer access methods to implement:

• [x] .post_service_info() for POST ​/service-info (#37 / #39)
• [x] .post_tool_class() for POST ​/toolClasses (#12)
• [x] .delete_tool_class() for DELETE ​/toolClasses​/{id} (#25 / #27)
• [x] .put_tool_class() for PUT ​/toolClasses​/{id} (#31 / #34)
• [x] .post_tool() for POST ​/tools (#21 / #23)
• [x] .delete_tool() for DELETE ​/tools​/{id} (#26 / #29)
• [x] .put_tool() for PUT ​/tools​/{id} (#32 / #35)
• [x] .post_version() for POST ​/tools​/{id}​/versions (#22 / #24)
• [x] .delete_version() for DELETE ​/tools​/{id}​/versions​/{version_id} (#28 / #30)
• [x] .put_version() for PUT ​/tools​/{id}​/versions​/{version_id} (#33 / #36)

Composite access methods to implement:

Please do not implement before issue is discussed/approved

• [ ] .import_tool(): import a tool from one TRS into another
• [ ] .get_checksums(): return dictionary of checksums for all files of a given descriptor type
• [x] .retrieve_files(): download all files of a given descriptor type (#8 / #9)
• [ ] .search_tools(): filter values of .get_tools() results for optionally exact (default) or partial matches in any field

[uniqueg]

The client is potentially very useful in our web portal CWLab. It's already used there (in v0.3.1 to retrieve workflow files if a "versioned TRS URI" is passed. But the TRS also offers a discovery endpoint (GET /tools with appropriate query parameters). To support the functionality of discovering a workflow that you don't know exists, implementing access methods for GET /tools, and then GET /tool/{id}, GET /tool/{id}/versions, and GET /tools/{id}/versions/{version_id} to allow the user to pick a version of a tool they have just discovered, are probably highest priority (pretty much in that order).

Afterwards, probably the POST, PUT and DELETE endpoints to manage resources available on the service (i.e., POST /tools and POST /tools/{id}/versions etc) are probably the next most important set of access methods.