Open thomasbeaudry opened 5 years ago
This issue has been automatically marked as stale because it has not had recent activity. It will be closed if no further activity occurs. Thank you for your contributions.
There will be a endpoint for that. It will probably refer to cohorts
instead of subprojects
and it will probably be location at the root of our API.
Currently there doesn't exist a subproject endpoint for the API. My LORIS instance restricts access to data on the subproject level, so the normal project endpoint will return too much information. Essentially this new endpoint adds more granularity to the API to satisfy permissions.
The response format that I would envision would be:
Single Subproject
GET /projects/$ProjectName/$SubprojectName
Returns a 200 OK response if the project and subproject exist, and 404 Not Found if it does not (the same is true of any portion of the API under /projects/$ProjectName/$Subproject.)
The body of the request to /projects/$ProjectName/$SubprojectName will be an entity of the form:
Single Subproject Instruments
GET /projects/$ProjectName/$SubprojectName/instruments/
Will return a JSON object of the form:
Single subproject images
GET /projects/$ProjectName/$Subproject/images/
Will return a JSON object of the form:
Single subproject visits
GET /projects/$ProjectName/$Subproject/visits/
Will return a JSON object of the form:
Single subproject candidates
GET /projects/$ProjectName/$Subproject/candidates/
will return a JSON object of the form:
Also, as a side note, I think that if you wanted to omit the $ProjectName from the GET calls to shorten them, then you would need to do something like:
GET /subprojects/$Subproject
Thanks!