As developer I want an api endpoint such that that when I send a GET request to the URL, hateoas compliant, paginated list of all efoTraits in the database is returned in JSON Format.
Management Rules
Rule 1: Endpoint - /v1/efo-traits
Rule 2: HTTP Request Method - GET
Rule 3: Endpoint should accept search, page and sort parameters as in /v1/efo-traits?page=0&size=20&sort=name,desc
Rule 4: Endpoint should be accessible to all
Rule 5: HATEOAS, sorting, pagination, and some search and filter specification
Rule 6: Endpoints should be cached based on request parameters to amplify query speed
API Endpoint Search Parameters
A robust search feature be made available as before, but designed in line with REST standards, this will automatically eliminate the need for 5 redundant endpoints as it was in the existing design, listed below. Therefore the /v1/efo-traits endpoint should accept search filter parameters as in /v1/efo-traits?{search_parameter}=
As developer I want an api endpoint such that that when I send a GET request to the URL, hateoas compliant, paginated list of all efoTraits in the database is returned in JSON Format.
This will be a replacement to the old endpoint https://www.ebi.ac.uk/gwas/rest/api/efoTraits
Management Rules Rule 1: Endpoint - /v1/efo-traits Rule 2: HTTP Request Method - GET Rule 3: Endpoint should accept search, page and sort parameters as in /v1/efo-traits?page=0&size=20&sort=name,desc Rule 4: Endpoint should be accessible to all Rule 5: HATEOAS, sorting, pagination, and some search and filter specification Rule 6: Endpoints should be cached based on request parameters to amplify query speed
API Endpoint Search Parameters A robust search feature be made available as before, but designed in line with REST standards, this will automatically eliminate the need for 5 redundant endpoints as it was in the existing design, listed below. Therefore the /v1/efo-traits endpoint should accept search filter parameters as in /v1/efo-traits?{search_parameter}=
Search Parameters:
Additional details here