- SLAC: Brian Van Klaveren, John Gates, Unknown User (danielw), Fabrice Jammes, Fritz Mueller, Andy Salnikov, Jacek Becla
- REST API General Guidelines
- very good proposal, discussion about small details around different edges
related to paging
might be worth returning total expected count
it is optional
- returning errors
- if we have an option to return specific error, specific context in json format (Eg this is my app 500 error, not apache), we will. Otherwise standard html error
- return everything we know about given error
bad sql statement - how will error msg look like?
- perhaps add additional container for this kind of errors
- query succeeded, but no results - how will the response look like?
- not through 204
- finding what is available / what functions the server can handle
- wadl (Web Application Description Language)
- want to move to sth self describing instead of static API page
- L3 users: will have a choice of direct queries, or RESTful API
- what about users connecting from outside?
- Need to understand what public services are visible from outside of LSST servers (question for Kian-Tat Lim)
- e.g., is everything going through RESTful API (and no direct queries) if connections are coming from outside world?
- forcing them to go through RESTful API would provide additional level of safety
- Gregory will open a story to capture this
python vs java
- Trey mildly concerned about using python in server side
- for performance reasons
- Thread per request?
- if API is truly RESTful, not much shared information on the server, so can have many servers, or multiple python back ends for apache
- universal for both python and java: web load balancer (like nginx)
- java could be more efficient, depends how it is written
- easier to connect to pipelines code from python
- rewrite from python to java shouldn't be too hard