We would like in the longer-term to provide a documented functional REST API service. How would that work with https://scimodom.dieterichlab.org ?
Although most API endpoints should be safe by now to be reached directly, I believe there still may be some unhandled cases, unspecific error handling, etc. Some endpoints were initially designed, for simplicity, assuming they would receive validated data only from the frontend, and thus may fail in general, e.g.http://127.0.0.1:5000/api/v0/modification/
Other endpoints, e.g. those related to the Compare view, may be more complicated to handle. I don't know if there is a general recommended way to handle APIs with endpoints that are generally accessible, endpoints that only make sense to be called from the web application frontend, and secure endpoints?
See also #74.
A clear and concise description of todo items.
The first thing to do is to go through all endpoints, and make sure they all have proper "data validation", adequate error handling, and to handle restricted endpoints appropriately.
Aims/objectives.
We would like in the longer-term to provide a documented functional REST API service. How would that work with https://scimodom.dieterichlab.org ?
Although most API endpoints should be safe by now to be reached directly, I believe there still may be some unhandled cases, unspecific error handling, etc. Some endpoints were initially designed, for simplicity, assuming they would receive validated data only from the frontend, and thus may fail in general, e.g. http://127.0.0.1:5000/api/v0/modification/
Other endpoints, e.g. those related to the Compare view, may be more complicated to handle. I don't know if there is a general recommended way to handle APIs with endpoints that are generally accessible, endpoints that only make sense to be called from the web application frontend, and secure endpoints?
See also #74.
A clear and concise description of todo items.