author Dustin J. Mitchell <>
Wed, 22 Jan 2014 08:36:59 -0500
changeset 232 03dce877d18892baeecdf200da1785a12488412e
parent 222 36bf9b0d9957cabf6d8bce4350d95c655e085db8
permissions -rw-r--r--
Bug 957385: memcached requires keys be bytestrings; r=catlee

Implementation Notes

This file outlines some of the implementation details of the REST API of

Or, how do URLs get turned into method calls?

Look in buildapi/config/  All the /builds/ urls are to support

URLs get matched to an appropriate route based on these rules, and then
methods in buildapi/controllers/ 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.

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/ receives
the message, acts on it, and then sends a message on the 'finished' routing
key to indicate the job was completed.

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.