User:Catlee/BuildAPI: Difference between revisions

Line 74: Line 74:


= Implementation Notes =
= Implementation Notes =
(source at http://hg.mozilla.org/users/catlee_mozilla.com/buildapi/file/493320c66935/RESTAPI_NOTES.txt)
== Routing ==
Or, how do URLs get turned into method calls?
Look in buildapi/config/routing.py.  All the /builds/ urls are to support
the REST API.
URLs get matched to an appropriate route based on these rules, and then
methods in buildapi/controllers/builds.py are called.
== GETting data ==
Most GET queries do a few simple operations:
1) validate parameters
2) make db calls with methods in buildapi/model/builds
3) return results
Results are formatted according to the 'format' query parameter
("?format=html" or "?format=json").  If 'format' is not set, and the
'Accept' header of the request is set to 'application/json', the format
will be set to json.  Otherwise the format will be html.  These rules are
implemented in buildapi.lib.base.BaseController._get_method_args.
== Job Requests ==
PUT, POST, and DELETE requests (which can be faked by setting a '_method_'
field to 'PUT' or 'DELETE' in a regular POST request if your client doesn't
support PUT/DELETE easiliy...a nice feature of Routes!) represent requests
to change buildbot state.  These are called "Job Requests".
Job requests follow a simple flow:
1) log request in jobrequests table of buildapi database.  Return
jobrequest id to client.  The client can query the status of this job via
the /builds/job_status/{job_id} method.
2) send message to message broker on the 'requests' routing key with
details of job request.
3) an external agent (such as buildapi/scripts/buildapi-agent.py) receives
the message, acts on it, and then sends a message on the 'finished' routing
key to indicate the job was completed.
TODO: agent should have a way of attaching failure information
4) a thread in the web app is waiting for messages on the 'finished'
routing key.  It will update the jobrequests table when jobs are completed.
Confirmed users
2,456

edits