-
Notifications
You must be signed in to change notification settings - Fork 2
Web API
The system was designed to use a custom web-based user interface (using sessions), but a REST API has also been implemented to provide separation of concerns and the potential for other forms of interaction (such as single page applications and mobile apps).
This page specifies the interface which is used to make AJAX calls during normal operation of the website. All communications are in JSON.
Public denotes that the client does not have to be logged in or authorized to make use of API call.
When a request is made (regardless of whether it's part of the REST API), a unified authorization method is used to check whether the client is authorized to make such requests. This methods first checks the HTTP request, and if that fails, looks up session data. Thus the same controllers can be used to handle both standard REST calls and AJAX requests (authorizing using sessions) from the web interface.
The current HTTP method only allows Basic authentication using the Authorization header. The alternative method of attaching the credentials to the URI (i.e. user:password @example.com) will not work. While the HTTP Authorization header also allows for other methods, including the more common OAuth used for RESTful services, support for this is currently not a high priority.
The web interface is currently being converted into a single page application. However, until this is complete, sessions support will remain. While all requests to the server are currently authenticated by checking the authorization header, if the HTTP Authorization fails, the server falls back to checking session data to verify if the client is authorized (logged-in). Only when this fails, does the server return an error message/status.
The session data can be set after the user logins, registers, or changes passwords (see the API specification for details). It can be unset by attaching ?action=logout when making a GET request to the login page.