Confirmed users
1,927
edits
BMO/Integration Best Practice: Difference between revisions
Update links, add info about BzAPI compat
(→API) |
(Update links, add info about BzAPI compat) |
||
| Line 1: | Line 1: | ||
If you are writing tools to integrate with bugzilla.mozilla.org (BMO), you want to make sure they keep working as intended as Bugzilla changes, and they avoid placing strain on the Bugzila infrastructure. Here are some tips and suggestions: | If you are writing tools to integrate with bugzilla.mozilla.org (BMO), you want to make sure they keep working as intended as Bugzilla changes, and that they avoid placing strain on the Bugzila infrastructure. Here are some tips and suggestions: | ||
== Guidelines == | == Guidelines == | ||
* '''Do not poll more frequently than every 5 minutes''' | * '''Use the [[Bugzilla:REST_API|native REST API]].''' | ||
** Seriously, you don't need to poll every minute | ** The older REST API, [[Bugzilla:BzAPI|BzAPI]], is deprecated. If you have an application currently using BzAPI, convert it to use the native API if possible; if you don't have the time/resources for that, at least switch to the [[Bugzilla:BzAPI:CompatLayer|native BzAPI-compatibility layer]], since BzAPI will be decommissioned at some point. | ||
* '''Ask for bugs updated since your last poll, or track a bug's last modified date''' | * '''Do not poll more frequently than every 5 minutes.''' | ||
** Seriously, you don't need to poll every minute. | |||
* '''Ask for bugs updated since your last poll, or track a bug's last modified date.''' | |||
** If your system is polling for bugs, you should ask BMO for bugs updated since your last poll. | ** If your system is polling for bugs, you should ask BMO for bugs updated since your last poll. | ||
** The chfieldfrom argument will accept times as well as dates (eg. "2012-10-08 00:00") | ** The chfieldfrom argument will accept times as well as dates (eg. "2012-10-08 00:00"). | ||
** Search results generally return a bug's last-modified date; there's no need to re-request the bug if it hasn't been modified since the last time you saw it | ** Search results generally return a bug's last-modified date; there's no need to re-request the bug if it hasn't been modified since the last time you saw it. | ||
* '''Only request the fields that you are interested in''' | * '''Only request the fields that you are interested in.''' | ||
** By default all APIs return more information than you probably require | ** By default all APIs return more information than you probably require—use the ''include_fields'' parameter to specify the exact fields you need ([[Bugzilla:BzAPI#Field_Control|BzAPI]], [http://www.bugzilla.org/docs/4.0/en/html/api/Bugzilla/WebService.html#Limiting_What_Fields_Are_Returned native REST and XMLRPC/JSONRPC]). | ||
** When searching with BzAPI, avoid specifying [ | ** When searching with BzAPI, avoid specifying [[Bugzilla:REST_API:Objects#Bug|non-bold columns]] if you can avoid it, because it'll be slower and user server-side resources. | ||
* '''Coalesce queries where possible''' | * '''Coalesce queries where possible.''' | ||
** If you have multiple bugs, components, etc to query, it can be more efficient issue a single request rather than iterating over your list and issuing multiple requests | ** If you have multiple bugs, components, etc., to query, it can be more efficient issue a single request rather than iterating over your list and issuing multiple requests. | ||
== API == | == API == | ||
Bugzilla's [[ | Bugzilla's [[Bugzilla:REST_API|REST]], XML-RPC, and JSON-RPC APIs have stability commitments within a major version of Bugzilla, as long as the call in question is not marked as experimental (see the API docs for the version in question). Other more ad-hoc ways of integrating, such as buglists-as-CSV and bugs-as-XML, don't have such commitments. Pick a stable API to use. | ||
== Searching == | == Searching == | ||