canmove, Confirmed users
6,441
edits
No edit summary |
|||
| Line 30: | Line 30: | ||
=== UI === | === UI === | ||
TBD | TBD | ||
=== API === | |||
Both the build machine client and the web administration API will make use of the REST interface described below: | |||
{| class="wikitable" | |||
|- | |||
! URI | |||
! Method | |||
! Parameters | |||
! Description | |||
|- | |||
| /releases | |||
| GET | |||
| | |||
| Retrieves all release names | |||
|- | |||
| /releases/[name] | |||
| GET | |||
| | |||
| Retrieve the release identified by "name" | |||
|- | |||
| /releases/[name] | |||
| PUT | |||
| details - the JSON blob associated with this release | |||
| Update the release with the supplied JSON data. If non-existent, it is created. Be careful when using this for existing releases that already have builds added to them -- the JSON blob given here overrides all data for the release, not just platform independent data. | |||
|- | |||
| /releases/[name] | |||
| DELETE | |||
| | |||
| Delete the release | |||
|- | |||
| /releases/[name]/builds | |||
| GET | |||
| | |||
| Retrieve all builds from a release | |||
|- | |||
| /releases/[name]/builds/[platform]/[locale] | |||
| GET | |||
| | |||
| Retrieve a specific build from a release | |||
|- | |||
| /releases/[name]/builds/[platform]/[locale] | |||
| PUT | |||
| details - the JSON blob associated with this build | |||
| Update the build with the supplied JSON data. If non-existent, it is created. | |||
|- | |||
| /releases/[name]/builds/[platform]/[locale] | |||
| DELETE | |||
| | |||
| Delete the build | |||
|- | |||
| rowspan=15 | /rule | |||
| rowspan=15 | POST | |||
| priority | |||
| rowspan=15 | Create a new rule with the supplied parameters. | |||
|- | |||
| mapping | |||
|- | |||
| throttle | |||
|- | |||
| update_type | |||
|- | |||
| product | |||
|- | |||
| version | |||
|- | |||
| channel | |||
|- | |||
| buildTarget | |||
|- | |||
| buildID | |||
|- | |||
| locale | |||
|- | |||
| osVersion | |||
|- | |||
| distribution | |||
|- | |||
| distVersion | |||
|- | |||
| headerArchitecture | |||
|- | |||
| comment | |||
|- | |||
| /rule | |||
| GET | |||
| Same as /rule POST | |||
| Retrieve all of the rules that match the specified parameters. Any missing parameters are regarded as wildcards, therefore a request with no parameters returns all rules. | |||
|- | |||
| /rule/[id] | |||
| PUT | |||
| Same as /rule POST | |||
| Replace the rule with the supplied parameters. Any missing parameters will be considered NULL. | |||
|- | |||
| /rule/[id] | |||
| POST | |||
| Same as /rule POST | |||
| Update the rule with any parameters passed. Any missing parameters will not be changed. | |||
|- | |||
| /rule/[id] | |||
| DELETE | |||
| | |||
| Delete the rule | |||
|} | |||
== Footnotes == | == Footnotes == | ||
<span id="note1">1. $product-$channel-latest only works in a world where no channel names overlap, which we should be in once 1.9.2 is dead. Doing it this way ensures that we nightly updates work after version bumps happen *and* we don't need to maintain a branch name <-> version mapping a la existing AUS.</span> | <span id="note1">1. $product-$channel-latest only works in a world where no channel names overlap, which we should be in once 1.9.2 is dead. Doing it this way ensures that we nightly updates work after version bumps happen *and* we don't need to maintain a branch name <-> version mapping a la existing AUS.</span> | ||