Bugzilla:BzAPI: Difference between revisions

mNo edit summary
 
(80 intermediate revisions by 8 users not shown)
Line 1: Line 1:
<div style="border: thin dotted #aaa; padding:5px;">
'''This specific REST API, generally referred to as "BzAPI", is DEPRECATED. For new projects, use the [[Bugzilla:REST_API|native REST API]] instead. The BMO team has implemented a [[Bugzilla:BzAPI:CompatLayer|compatibility layer]] to help existing apps transition off BzAPI onto the native REST API. Please migrate existing BzAPI-based apps to the new compatibility-layer endpoint as soon as possible, as BzAPI will be shut off at some point in the future. Direct any questions to the [[BMO]] team.
'''The native REST API is available in Bugzilla 5.0 and up, and on bugzilla.mozilla.org.  Although BzAPI is deprecated, it can be used with older Bugzilla installations (versions prior to 5.0) to provide a REST API.'''
</div><br>
These pages document the tip of the HTTP REST API for Bugzilla proxy software ("BzAPI"). Please file bugs (in either code or documentation) in [https://bugzilla.mozilla.org/enter_bug.cgi?product=Webtools&component=BzAPI the BzAPI component in bugzilla.mozilla.org].
These pages document the tip of the HTTP REST API for Bugzilla proxy software ("BzAPI"). Please file bugs (in either code or documentation) in [https://bugzilla.mozilla.org/enter_bug.cgi?product=Webtools&component=BzAPI the BzAPI component in bugzilla.mozilla.org].


There is a page where you can add [[Bugzilla:REST_API:HowTo|tips, tricks and code samples]].
This page contains general information and preliminaries. Read it first. Then, you can find more detailed information:
 
* [https://wiki.mozilla.org/Bugzilla:BzAPI:Methods API Methods]
** [https://wiki.mozilla.org/Bugzilla:BzAPI:Search Parameters for the Search method]
* [https://wiki.mozilla.org/Bugzilla:BzAPI:Objects Objects sent and received]
** [https://wiki.mozilla.org/Bugzilla:BzAPI:Objects:Configuration The Configuration object]
* [https://wiki.mozilla.org/Bugzilla:BzAPI:HowTo Tips, tricks and code samples]


==Versions==
==Versions==
Line 7: Line 19:
Older pages in this wiki document released versions of BzAPI.
Older pages in this wiki document released versions of BzAPI.


===Version 0.1 (4th October 2009)===
===Version 1.3 (7th March 2013)===


* [https://wiki.mozilla.org/index.php?title=Bugzilla:REST_API&oldid=173071 Bugzilla:REST_API]
* [https://wiki.mozilla.org/index.php?title=Bugzilla:BzAPI&oldid=538111 Overview]
* [https://wiki.mozilla.org/index.php?title=Bugzilla:REST_API:Objects&oldid=173069 Bugzilla:Rest_API:Objects]
* [https://wiki.mozilla.org/index.php?title=Bugzilla:BzAPI:Methods&oldid=436589 API Methods]
* [https://wiki.mozilla.org/index.php?title=Bugzilla:REST_API:Search&oldid=173242 Bugzilla:Rest_API:Search]
** [https://wiki.mozilla.org/index.php?title=Bugzilla:BzAPI:Search&oldid=483668 Parameters for the Search method]
* [https://wiki.mozilla.org/index.php?title=Bugzilla:BzAPI:Objects&oldid=537941 Objects sent and received]
** [https://wiki.mozilla.org/index.php?title=Bugzilla:BzAPI:Objects:Configuration&oldid=265440 The Configuration object]
* [https://wiki.mozilla.org/index.php?title=Bugzilla:BzAPI:HowTo&oldid=489309 Tips, tricks and code samples]


===Version 0.2 (11th November 2009)===
===Version 1.2 (21st November 2012)===


* [https://wiki.mozilla.org/index.php?title=Bugzilla:REST_API&oldid=181921 Bugzilla:REST_API]
* [https://wiki.mozilla.org/index.php?title=Bugzilla:BzAPI&oldid=358475 Overview]
* [https://wiki.mozilla.org/index.php?title=Bugzilla:REST_API:Objects&oldid=181924 Bugzilla:Rest_API:Objects]
* [https://wiki.mozilla.org/index.php?title=Bugzilla:BzAPI:Methods&oldid=436589 API Methods]
* [https://wiki.mozilla.org/index.php?title=Bugzilla:REST_API:Objects:Configuration&oldid=178374 Bugzilla:Rest_API:Objects:Configuration]
** [https://wiki.mozilla.org/index.php?title=Bugzilla:BzAPI:Search&oldid=483668 Parameters for the Search method]
* [https://wiki.mozilla.org/index.php?title=Bugzilla:REST_API:Search&oldid=181932 Bugzilla:Rest_API:Search]
* [https://wiki.mozilla.org/index.php?title=Bugzilla:BzAPI:Objects&oldid=292055 Objects sent and received]
** [https://wiki.mozilla.org/index.php?title=Bugzilla:BzAPI:Objects:Configuration&oldid=265440 The Configuration object]
* [https://wiki.mozilla.org/index.php?title=Bugzilla:BzAPI:HowTo&oldid=295460 Tips, tricks and code samples]


==Servers==
==Servers==


The existing implementation of the API is a proxy which can be installed and pointed at any Bugzilla (version 3.4 or above for full capabilities). An installation of the latest version, pointed at https://bugzilla.mozilla.org/, can be found at:
Installations of the API are available pointed at two Bugzilla servers - the main Mozilla one and the testing server. '''Please use the testing server for testing API clients.''' You can also use a specific version of the API, or just "the latest version".


[https://api-dev.bugzilla.mozilla.org/0.3/ https://api-dev.bugzilla.mozilla.org/0.3/]
Main Mozilla server (https://bugzilla.mozilla.org/):


There is a test Bugzilla server at https://bugzilla-stage-tip.mozilla.org/. There is a version of the API pointed at this server, which should be used for testing API clients:
[https://api-dev.bugzilla.mozilla.org/1.3/ https://api-dev.bugzilla.mozilla.org/1.3/]
[https://api-dev.bugzilla.mozilla.org/latest/ https://api-dev.bugzilla.mozilla.org/latest/]


[https://api-dev.bugzilla.mozilla.org/stage/0.3/ https://api-dev.bugzilla.mozilla.org/stage/0.3/]
Testing server (http://landfill.bugzilla.org/bzapi_sandbox/):


As the API is tweaked and revised, the version number in these URLs will increase, so updates don't break every single client immediately. However, old versions are not guaranteed to persist. Authors of API-using tools are strongly encouraged to join the [http://www.mozilla.org/community/developer-forums.html#tools mozilla.tools] mailing list to be kept up to date.
[https://api-dev.bugzilla.mozilla.org/test/1.3/ https://api-dev.bugzilla.mozilla.org/test/1.3/]
[https://api-dev.bugzilla.mozilla.org/test/latest/ https://api-dev.bugzilla.mozilla.org/test/latest/]


== Authentication ==
If you want to always use the same version, use URLs with a version number in. However, old ones are not guaranteed to persist. If you want to live on the  edge, use URLs with "latest" in. However, backwardly-incompatible changes are possible at the time of a new release.


The API and the proxy support anonymous access as much as the target Bugzilla does. If you want to authenticate, pass:
Authors of API-using tools are strongly encouraged to join the [http://www.mozilla.org/community/developer-forums.html#tools mozilla.tools] mailing list to be kept up to date on changes and new releases.


username=fred@bedrock.com&password=ilovewilma
==Browsing the API==


as query parameters on any request. The above-mentioned instance of the API is available over HTTPS and accesses bugzilla.mozilla.org over HTTPS.
If the Accept: header of a request is set to text/html (as it is by an ordinary web browser) then the API will return YAML-HTML, which the browser can display. In other words, you can play with the API using just your browser and see results in a human-readable form. [https://api-dev.bugzilla.mozilla.org/latest/bug/35 Here is an example]. This is a good way to try out the various GET calls, even if you can't use it for POST or PUT. For that, the [https://addons.mozilla.org/en-US/firefox/addon/9780 Firefox "RESTClient" addon] is very useful.
 
The cert on the API machine is signed by the [[MozillaRootCertificate|Mozilla Root CA]]. Its MD5 fingerprint is 75:B2:EF:89:81:51:8F:99:13:DC:BF:44:47:0E:A9:8D.


== Data Formats ==
== Data Formats ==


'''On every request, you must set both the "Accept" and "Content-Type" HTTP headers to the MIME type of the data format you are using to communicate with the API.''' Content-Type tells the API how to interpret your request, and Accept tells it how you want your data back.
Aside from the above-mentioned "browsing" facility, the REST API only supports [http://www.json.org/ JSON] input, and either JSON and [http://en.wikipedia.org/wiki/JSON#JSONP JSONP] output. So objects sent and received must be in JSON format.


Currently, the API has only been tested with JSON (MIME type: "application/json"). However, [http://search.cpan.org/~bobtfish/Catalyst-Action-REST-0.77/lib/Catalyst/Controller/REST.pm Catalyst::Controller::REST] supports a number of serialization and deserialization formats, and can be extended for more. Feel free to set "Accept: application/xml" and see what you get back, and then try feeding it back in again. But be aware that the XML output format, and any other non-JSON formats for that matter, are very much ''not'' frozen.
'''On every request, you must set both the "Accept" and "Content-Type" HTTP headers to the MIME type of the data format you are using to communicate with the API.''' Content-Type tells the API how to interpret your request, and Accept tells it how you want your data back. "Content-Type" must be "application/json". "Accept" can be either that, or "application/javascript" for JSONP - add a "callback" parameter to name your callback. (Due to [https://bugzilla.mozilla.org/show_bug.cgi?id=645945 a bug] in the Perl package Catalyst::Controller::REST, callbacks cannot contain dots.)


== Errors ==
== Authentication ==


All of the "output" documentation below documents successful returns :-) Calls may also return an [[Bugzilla:REST_API:Objects#Error|Error]].
The API and the proxy support anonymous access as much as the target Bugzilla does.  


The documentation below gives a list of possible values for the "message" field; the list is almost certainly not exhaustive. Error handling is always a large part of any good API, and is one place where this one might be a little rough. In the future, ponies will provide each possible error object with a single unambiguous error code in a "code" field. The other codes are not guaranteed to be present, or continue to be present if they are there now. The html_page, in particular, is only there so you can read it manually for a better idea of what the error was, and ask for the API to support it properly.
Note: The above-mentioned instance of the API is available over HTTPS and accesses bugzilla.mozilla.org over HTTPS. (The cert is from GeoTrust's Equifax root, which should be trusted by all current browsers.) So login information should be safe in transit.


== Conflicts ==
There are two ways to authenticate.


There are two calls (bug/<id> PUT and attachment/<id> PUT) where you can set any field on that bug or attachment, and those calls always check for editing conflicts. All other calls which change things unconditionally make things as you request, and require no conflict resolution.
====Username and Password Auth====


In the case of the two calls which check, conflict resolution must be implemented by the client. So if you call /bug/<id> PUT and the bug changed since your GET (i.e. the web interface would mid-air), you'll get an error, and your client will need to GET again, resolve the conflicts with the user using a UI of your choice, and attempt another PUT.
Pass e.g.:


== API Notes ==
username=fred@bedrock.com&password=ilovewilma


* All times are supplied as UTC, in the ISO 8601 extended format (e.g. "2009-06-21T12:34:56Z"). This should define the time unambiguously, and should be widely and easily parseable, at the expense of probably not being directly displayable without a little manipulation.
as query parameters on any request. Obviously, remember to URL encode any special characters, which are often seen in passwords.
* Votes are not supported.
* Examples are in JSON format because I had to pick one; see above regarding other formats.


== API Calls: Bugs ==
====Cookie Auth====
If you have access to some existing Bugzilla login cookies for the user, you can also authenticate using that. You pass the data as URL parameters rather than as Cookie headers to prevent cross-site request forgery (XSRF).


=== Search for bugs (/bug GET) ===
Note that the cookies are HTTPOnly and so you can't access this info from unprivileged in-page JavaScript. However, if you have chrome privileges, you can ask the cookie service.


'''Input'''
userid=1234&cookie=mG4J9OT4B6


A) [[Bugzilla:REST_API:Search|Search parameters]], exactly as powerful as query.cgi but using the field names from the Bug object rather than those from the web interface. (At the moment, it does also support the field names from the web interface, to make it easy to port URLs and other code across. But if supporting this becomes difficult, it might go away.)
The "userid" parameter is a numeric user ID, the contents of the "Bugzilla_login" cookie. The "cookie" parameter is a random string, the contents of the "Bugzilla_logincookie" cookie.


B) As above, with parameter count=1.
== Field Control ==


'''Output'''
For those calls which return significant data (i.e. GETs), each call returns a number of fields by default. Often, it's all available fields, but for some calls (e.g. bug lists, individual bugs) it's fewer than that. You can control exactly what fields you get using the '''include_fields''' and '''exclude_fields''' parameters. These take a comma-separated list of field names, and work as follows:


A)
* If you specify some include_fields, you select just those fields
* If one of your field names is "_default" (note underscore), you select the default fields plus any others you specify
* If one of your field names is "_all" (note underscore), you select all available fields, regardless of whether you specify any others as well
* After that, if you have specified exclude_fields, they are removed before the data is returned.


{ "bugs": [ <array of [[Bugzilla:REST_API:Objects#Bug|Bug]]> ] }
== Errors ==


B) Count of bugs:
If methods are not successful for whatever reason, they will return an [[Bugzilla:BzAPI:Objects#Error|Error]]. ''You should test every API return to see if it is an error ("error" member set to a true value).''


{ "count": 136 }
The "code" field on an Error, if present, will give an error code from [[Bugzilla:WebServices:Errors|this list]]. The other member variables of the object are not stable, and should not be relied upon. The html_page, in particular, is only there so you can read it manually for a better idea of what the error was, and ask for the API to support it properly.


'''Notes'''
==Your Own Installation==


* Only a subset of a bug's fields are returned on a search. These are those in bold on the [[Bugzilla:REST_API:Objects#Bug|list]]. As a rule of thumb, only single-valued fields are returned.
If you want to install the API proxy on your own machine for your own Bugzilla, you will need:


'''Errors'''
* the <b>latest</b> stable 3.4.x, 3.6.x, 4.0.x, 4.2.x or 4.4.x point release of Bugzilla (many features will not work on 3.2); and
* to be using UTF-8 (this is the default on new installations); and
* to have the necessary optional modules for XML-RPC (e.g. Test::Taint); and
* to apply the patches noted below.


=== Create new bug (/bug POST) ===
Then, install a copy of the API software - it does not have to be on the same machine. See the INSTALL file in the repository for some installation hints; feel free to send tips from your experience to gerv@mozilla.org.


'''Input'''
You can get the code from the Mozilla Mercurial (hg) repository:
 
[[Bugzilla:REST_API:Objects#Bug|Bug]] as POST body.
 
'''Output'''
 
201 Created status code, Location header pointing to new bug object.
 
{ "ref": "<same-as-location-header>" }
 
'''Notes'''
 
* You can't add attachments with a new bug. Any attachment fields in the bug object will be ignored. Make a separate call.
 
'''Errors'''
 
=== Retrieve bug (/bug/<id> GET) ===
 
'''Input'''
 
* Bug ID on the URL
* Includes flags, CC list, related bugs and attachment metadata by default
* Does not include attachment data, comments or history - so amount of data is bounded
* attachmentdata=1, comments=1 and history=1 do the obvious things (history requires 3.4)
* Multi-valued custom fields are not, in general, returned as arrays if there is 0 or 1 value. This is because I can't tell which custom fields are supposed to be multi-valued. As a hack, if your custom field name begins "cf_multi", it will get unconditionally array-ified. This limitation can only be lifted when the API is part of Bugzilla itself.
 
'''Output'''
 
[[Bugzilla:REST_API:Objects#Bug|Bug]].
 
'''Notes'''
 
* If you want to retrieve multiple [[Bugzilla:REST_API:Objects#Bug|Bug]]s at once, use the Search interface and specify only Bug IDs as your search criteria. You will be returned full [[Bugzilla:REST_API:Objects#Bug|Bug]] objects instead of the reduced number of fields normally presented on a Search. This is a shortcut to avoid people having to make 20 calls to get 20 full bug objects.
 
'''Errors'''
 
=== Update bug (/bug/<id> PUT) ===
 
'''Input'''
 
[[Bugzilla:REST_API:Objects#Bug|Bug]] as PUT body.
 
'''Output'''
 
{ "ok": 1 }
 
'''Notes'''
 
* You can only add one comment per call. Add a [[Bugzilla:REST_API:Objects#Comment|Comment]] object without an id to the comments array.
* This call does not support the updating of attachment metadata. Make a separate call to update attachments.
* Set assigned_to or qa_contact to the special value <tt>null</tt> (in JSON) to reset them to the default for the current component.
* To make this call check for conflicts, submit the last_change_time you received when getting the bug data. To make unconditional updates (be careful!) simply do not supply a last_change_time.
* You can update most fields singly, but some fields are coupled, and must be provided as a set (even if one has not changed), as follows:
** 'status' and 'resolution'
** 'blocks' and 'dependson'
** 'component' and 'product'
** 'version' and 'target_milestone' require 'product'
 
'''Errors'''
 
* This call will return a "Mid-air collision" error if you submit a last_change_time earlier than the one Bugzilla has on record.
 
=== List comments for bug (/bug/<id>/comment GET) ===
 
'''Input'''
 
* Bug ID on the URL
* "new_since" DateTime parameter (YYYYMMDDTHHMMSS format only) returns only ones since date given. (3.4 or above only)
 
'''Output'''
 
{ "comments": [ array of [[Bugzilla:REST_API:Objects#Comment|Comment]] ] }
 
In other words, a [[Bugzilla:REST_API:Objects#Bug|Bug]] with only the comment field.
 
'''Notes'''
 
* No comments (or none you can see) -> empty array.
 
'''Notes'''
 
'''Errors'''
 
=== Add new comment to bug (/bug/<id>/comment POST) ===
 
'''Input'''
 
[[Bugzilla:REST_API:Objects#Comment|Comment]] as POST body.
 
'''Output'''
 
201 Created status code, Location header pointing to bug/<id>/comment (as individual comments don't have their own location).
 
{ "ref": "<same-as-location-header>" }
 
'''Notes'''
 
* Unconditional - no conflict checking
 
'''Errors'''
 
 
=== List history for bug (/bug/<id>/history GET) ===
 
'''Input'''
 
* Bug ID on the URL.
 
'''Output'''
 
{ "history": [ array of [[Bugzilla:REST_API:Objects#ChangeSet|ChangeSet]] ] }
 
In other words, a [[Bugzilla:REST_API:Objects#Bug|Bug]] with only the history field.
 
'''Notes'''
 
* This call requires Bugzilla 3.4 or above.
 
'''Errors'''


=== List flags for bug (/bug/<id>/flag GET) ===
hg clone http://hg.mozilla.org/webtools/bzapi bzapi


'''Input'''
Each release is tagged in the form BZAPI_X.X_RELEASE, so feel free to pull a tag instead of the tip.


* Bug ID on the URL.
If you are installing on Ubuntu, you'll need at least the following modules (and probably many more):


'''Output'''
  sudo apt-get install libcatalyst-perl libcatalyst-modules-perl libcatalyst-action-rest-perl libtext-csv-xs-perl libarray-diff-perl libdata-walk-perl starman


{ "flags": [ array of [[Bugzilla:REST_API:Objects#Flag|Flag]] ] }
and the following Perl modules via CPAN:


In other words, a [[Bugzilla:REST_API:Objects#Bug|Bug]] with only the flags field.
  BZ::Client Catalyst::Plugin::Log::Handler Slurp


'''Notes'''
<b>Important Note</b>: Install BZ::Client 1.03, not the latest (1.04), because BZ::Client was updated to fix some problems but the workarounds in the BzAPI code have not yet been removed.


'''Errors'''
  perl -MCPAN -e "install 'JWIED/BZ-Client-1.03.tar.gz'"


== API Calls: Attachments ==
Also, I am told that BZ-Client requires Perl 5.10.0, which is a higher requirement than that for stable Bugzilla. (Bugzilla trunk requires 5.10, but 4.4 and below only require 5.8.)


=== List attachments for bug (/bug/<id>/attachment GET) ===
===Required Extension and/or Patch(es)===


'''Input'''
There are two changes you need to make.


* Bug ID on the URL.
Even the latest stable release of Bugzilla requires a little modification to work properly with the BzAPI. Unfortunately, it is not possible to support all the necessary functionality without some changes to Bugzilla itself, which the Bugzilla team have declined to take.  
* attachmentdata=1 does the obvious thing.
 
'''Output'''
 
{ "attachments": [ array of [[Bugzilla:REST_API:Objects#Attachment|Attachment]] ] }
 
In other words, a [[Bugzilla:REST_API:Objects#Bug|Bug]] with only the attachment field.
 
'''Notes'''
 
* No attachments -> empty array.
 
'''Errors'''
 
=== Create new attachment (/bug/<id>/attachment POST) ===
 
'''Input'''
 
[[Bugzilla:REST_API:Objects#Attachment|Attachment]] as POST body.
 
'''Output'''
 
201 Created status code, Location header pointing to new object.
 
{ "ref": "<same-as-location-header>" }
 
'''Notes'''
 
* You can't set is_obsolete on a new attachment submission
* You can't set the same (multi-settable) flag twice on a single attachment submission
 
'''Errors'''
 
=== Retrieve attachment (/attachment/<id> GET) ===
 
'''Input'''
 
* Attachment ID on the URL.
* attachmentdata=1 does the obvious thing.
 
'''Output'''
 
[[Bugzilla:REST_API:Objects#Attachment|Attachment]].
 
'''Notes'''
 
'''Errors'''
 
=== Update attachment metadata (/attachment/<id> PUT) ===
 
'''Input'''
 
[[Bugzilla:REST_API:Objects#Attachment|Attachment]] as PUT body.
 
'''Output'''
 
{ "ok": 1 }
 
'''Notes'''
 
* You can't set the same (multi-settable) flag twice on a single attachment submission
* To make this call check for conflicts, submit the last_change_time you received when getting the attachment data. To make unconditional updates (be careful!) simply do not supply a last_change_time.
 
'''Errors'''
 
== API Calls: Users ==
 
=== Search for users (/user GET) ===
 
'''Input'''
 
* "match" parameter with string to match against either name or real_name.
 
'''Output'''
 
{ users: [ array of [[Bugzilla:REST_API:Objects#User|User]] ] }
 
'''Notes'''
 
* No matches -> empty array.
* This call requires Bugzilla 3.4 or above.
 
'''Errors'''
 
=== Retrieve user (/user/<id> GET) ===
 
'''Input'''
 
User ID on the URL. Can be numeric ID or email address.
 
'''Output'''
 
[[Bugzilla:REST_API:Objects#User|User]].
 
'''Notes'''
 
* This call requires Bugzilla 3.4 or above.
 
'''Errors'''
 
== API Calls: Other ==
 
=== Configuration (/configuration GET) ===
 
'''Input'''
 
* None
 
'''Output'''
 
[[Bugzilla:REST_API:Objects:Configuration|Configuration]]
 
'''Notes'''
 
* flags=0 parameter removes flag-related information from the config; because flags can be enabled or disabled per-component, there is a lot of flag-related info and so this cuts down the size significantly. However, you will not be able to add new flags to bugs or attachments without this info.
 
'''Errors'''
 
==Your Own Installation==
 
If you want to install the API proxy on your own machine for your own Bugzilla, you will need:
 
* the latest stable 3.4.x release of Bugzilla (many features will not work on 3.2); and
* to be using UTF-8 (this is the default on new installations).
 
Then, install a copy of the API software - it does not have to be on the same machine. See the INSTALL file in the repository for some installation hints; feel free to send me tips from your experience.
 
You can get the code from the Mozilla Mercurial (hg) repository:


hg co http://hg.mozilla.org/webtools/bzapi bzapi
So, firstly, for Bugzilla 3.6 and above, there is a Bugzilla Extension which adds the necessary functionality. Find it in <tt>$BZAPI_HOME/extension</tt>; copy the <tt>BzAPI</tt> directory from there into <tt>$BUGZILLA_HOME/extensions</tt>.


===Patches===
If you are on 3.4 or below, you need a patch and a template. These are shipped in the BzAPI distribution, in the <tt>patches</tt> directory, from version 0.8 onwards. See the INSTALL file for details.


Even on top of the latest stable release of Bugzilla 3.4, you will need to apply a few further patches. (Unfortunately, it was not possible to support all the necessary functionality without some changes to Bugzilla itself, which were considered either unnecessary or too intrusive for a stable release series.)
Secondly, if you are using non-ASCII characters at all, you need to patch the BZ::Client module, which has an encoding bug. The patch for that is also in the <tt>patches</tt> directory.


[https://bugzilla.mozilla.org/show_bug.cgi?id=521398 Make legacy XML interface supply more data (flags, etc.)] - for 3.4 stable you'll need patch version 8a.
[[category:Bugzilla]]
* [https://bugzilla.mozilla.org/show_bug.cgi?id=523325 JSON template for config.cgi] (note: you'll need the original patch and then the updated config.json.tmpl)

Latest revision as of 02:03, 21 September 2016

This specific REST API, generally referred to as "BzAPI", is DEPRECATED. For new projects, use the native REST API instead. The BMO team has implemented a compatibility layer to help existing apps transition off BzAPI onto the native REST API. Please migrate existing BzAPI-based apps to the new compatibility-layer endpoint as soon as possible, as BzAPI will be shut off at some point in the future. Direct any questions to the BMO team.

The native REST API is available in Bugzilla 5.0 and up, and on bugzilla.mozilla.org. Although BzAPI is deprecated, it can be used with older Bugzilla installations (versions prior to 5.0) to provide a REST API.


These pages document the tip of the HTTP REST API for Bugzilla proxy software ("BzAPI"). Please file bugs (in either code or documentation) in the BzAPI component in bugzilla.mozilla.org.

This page contains general information and preliminaries. Read it first. Then, you can find more detailed information:

Versions

Older pages in this wiki document released versions of BzAPI.

Version 1.3 (7th March 2013)

Version 1.2 (21st November 2012)

Servers

Installations of the API are available pointed at two Bugzilla servers - the main Mozilla one and the testing server. Please use the testing server for testing API clients. You can also use a specific version of the API, or just "the latest version".

Main Mozilla server (https://bugzilla.mozilla.org/):

https://api-dev.bugzilla.mozilla.org/1.3/
https://api-dev.bugzilla.mozilla.org/latest/

Testing server (http://landfill.bugzilla.org/bzapi_sandbox/):

https://api-dev.bugzilla.mozilla.org/test/1.3/
https://api-dev.bugzilla.mozilla.org/test/latest/

If you want to always use the same version, use URLs with a version number in. However, old ones are not guaranteed to persist. If you want to live on the edge, use URLs with "latest" in. However, backwardly-incompatible changes are possible at the time of a new release.

Authors of API-using tools are strongly encouraged to join the mozilla.tools mailing list to be kept up to date on changes and new releases.

Browsing the API

If the Accept: header of a request is set to text/html (as it is by an ordinary web browser) then the API will return YAML-HTML, which the browser can display. In other words, you can play with the API using just your browser and see results in a human-readable form. Here is an example. This is a good way to try out the various GET calls, even if you can't use it for POST or PUT. For that, the Firefox "RESTClient" addon is very useful.

Data Formats

Aside from the above-mentioned "browsing" facility, the REST API only supports JSON input, and either JSON and JSONP output. So objects sent and received must be in JSON format.

On every request, you must set both the "Accept" and "Content-Type" HTTP headers to the MIME type of the data format you are using to communicate with the API. Content-Type tells the API how to interpret your request, and Accept tells it how you want your data back. "Content-Type" must be "application/json". "Accept" can be either that, or "application/javascript" for JSONP - add a "callback" parameter to name your callback. (Due to a bug in the Perl package Catalyst::Controller::REST, callbacks cannot contain dots.)

Authentication

The API and the proxy support anonymous access as much as the target Bugzilla does.

Note: The above-mentioned instance of the API is available over HTTPS and accesses bugzilla.mozilla.org over HTTPS. (The cert is from GeoTrust's Equifax root, which should be trusted by all current browsers.) So login information should be safe in transit.

There are two ways to authenticate.

Username and Password Auth

Pass e.g.:

username=fred@bedrock.com&password=ilovewilma

as query parameters on any request. Obviously, remember to URL encode any special characters, which are often seen in passwords.

Cookie Auth

If you have access to some existing Bugzilla login cookies for the user, you can also authenticate using that. You pass the data as URL parameters rather than as Cookie headers to prevent cross-site request forgery (XSRF).

Note that the cookies are HTTPOnly and so you can't access this info from unprivileged in-page JavaScript. However, if you have chrome privileges, you can ask the cookie service.

userid=1234&cookie=mG4J9OT4B6

The "userid" parameter is a numeric user ID, the contents of the "Bugzilla_login" cookie. The "cookie" parameter is a random string, the contents of the "Bugzilla_logincookie" cookie.

Field Control

For those calls which return significant data (i.e. GETs), each call returns a number of fields by default. Often, it's all available fields, but for some calls (e.g. bug lists, individual bugs) it's fewer than that. You can control exactly what fields you get using the include_fields and exclude_fields parameters. These take a comma-separated list of field names, and work as follows:

  • If you specify some include_fields, you select just those fields
  • If one of your field names is "_default" (note underscore), you select the default fields plus any others you specify
  • If one of your field names is "_all" (note underscore), you select all available fields, regardless of whether you specify any others as well
  • After that, if you have specified exclude_fields, they are removed before the data is returned.

Errors

If methods are not successful for whatever reason, they will return an Error. You should test every API return to see if it is an error ("error" member set to a true value).

The "code" field on an Error, if present, will give an error code from this list. The other member variables of the object are not stable, and should not be relied upon. The html_page, in particular, is only there so you can read it manually for a better idea of what the error was, and ask for the API to support it properly.

Your Own Installation

If you want to install the API proxy on your own machine for your own Bugzilla, you will need:

  • the latest stable 3.4.x, 3.6.x, 4.0.x, 4.2.x or 4.4.x point release of Bugzilla (many features will not work on 3.2); and
  • to be using UTF-8 (this is the default on new installations); and
  • to have the necessary optional modules for XML-RPC (e.g. Test::Taint); and
  • to apply the patches noted below.

Then, install a copy of the API software - it does not have to be on the same machine. See the INSTALL file in the repository for some installation hints; feel free to send tips from your experience to gerv@mozilla.org.

You can get the code from the Mozilla Mercurial (hg) repository:

hg clone http://hg.mozilla.org/webtools/bzapi bzapi

Each release is tagged in the form BZAPI_X.X_RELEASE, so feel free to pull a tag instead of the tip.

If you are installing on Ubuntu, you'll need at least the following modules (and probably many more):

 sudo apt-get install libcatalyst-perl libcatalyst-modules-perl libcatalyst-action-rest-perl libtext-csv-xs-perl libarray-diff-perl libdata-walk-perl starman

and the following Perl modules via CPAN:

 BZ::Client Catalyst::Plugin::Log::Handler Slurp

Important Note: Install BZ::Client 1.03, not the latest (1.04), because BZ::Client was updated to fix some problems but the workarounds in the BzAPI code have not yet been removed.

 perl -MCPAN -e "install 'JWIED/BZ-Client-1.03.tar.gz'"

Also, I am told that BZ-Client requires Perl 5.10.0, which is a higher requirement than that for stable Bugzilla. (Bugzilla trunk requires 5.10, but 4.4 and below only require 5.8.)

Required Extension and/or Patch(es)

There are two changes you need to make.

Even the latest stable release of Bugzilla requires a little modification to work properly with the BzAPI. Unfortunately, it is not possible to support all the necessary functionality without some changes to Bugzilla itself, which the Bugzilla team have declined to take.

So, firstly, for Bugzilla 3.6 and above, there is a Bugzilla Extension which adds the necessary functionality. Find it in $BZAPI_HOME/extension; copy the BzAPI directory from there into $BUGZILLA_HOME/extensions.

If you are on 3.4 or below, you need a patch and a template. These are shipped in the BzAPI distribution, in the patches directory, from version 0.8 onwards. See the INSTALL file for details.

Secondly, if you are using non-ASCII characters at all, you need to patch the BZ::Client module, which has an encoding bug. The patch for that is also in the patches directory.