Bugzilla::WebService - The Web Service interface to Bugzilla
This is the standard API for external programs that want to interact with Bugzilla. It provides various methods in various modules.
Currently the only method of accessing the API is via XML-RPC. The XML-RPC standard is described here: http://www.xmlrpc.com/spec
The endpoint for Bugzilla WebServices is the xmlrpc.cgi script in your Bugzilla installation.
For example,
if your Bugzilla is at bugzilla.yourdomain.com,
then your XML-RPC client would access the API via: http://bugzilla.yourdomain.com/xmlrpc.cgi
Methods are called in the normal XML-RPC fashion. Bugzilla does not currently implement any extensions to the standard method of XML-RPC method calling.
Methods are grouped into "packages",
like Bug for Bugzilla::WebService::Bug.
So,
for example,
"get" in Bugzilla::WebService::Bug,
is called as Bug.get in XML-RPC.
In addition to the standard parameter types like int,
string,
etc.,
XML-RPC has two data structures,
a <struct> and an <array>.
In Perl,
we call a <struct> a "hash" or a "hashref".
You may see us refer to it that way in the API documentation.
In example code,
you will see the characters { and } used to represent the beginning and end of structs.
For example, here's a struct in XML-RPC:
<struct>
<member>
<name>fruit</name>
<value><string>oranges</string></value>
</member>
<member>
<name>vegetable</name>
<value><string>lettuce</string></value>
</member>
</struct>
In our example code in these API docs, that would look like:
{ fruit => 'oranges', vegetable => 'lettuce' }
In example code, you will see the characters [ and ] used to represent the beginning and end of arrays.
For example, here's an array in XML-RPC:
<array>
<data>
<value><i4>1</i4></value>
<value><i4>2</i4></value>
<value><i4>3</i4></value>
</data>
</array>
In our example code in these API docs, that would look like:
[1, 2, 3]
All Bugzilla WebServices functions take their parameters in a <struct>. Another way of saying this would be: All functions take a single argument, a <struct> that contains all parameters. The names of the parameters listed in the API docs for each function are the name element for the struct members.
You can use "login" in Bugzilla::WebService::User to log in as a Bugzilla user. This issues standard HTTP cookies that you must then use in future calls, so your XML-RPC client must be capable of receiving and transmitting cookies.
Methods are marked STABLE if you can expect their parameters and return values not to change between versions of Bugzilla. You are best off always using methods marked STABLE. We may add parameters and additional items to the return values, but your old code will always continue to work with any new changes we make. If we ever break a STABLE interface, we'll post a big notice in the Release Notes, and it will only happen during a major new release.
Methods (or parts of methods) are marked EXPERIMENTAL if we believe they will be stable, but there's a slight chance that small parts will change in the future.
Certain parts of a method's description may be marked as UNSTABLE, in which case those parts are not guaranteed to stay the same between Bugzilla versions.
If a particular webservice call fails, it will throw a standard XML-RPC error. There will be a numeric error code, and then the description field will contain descriptive text of the error. Each error that Bugzilla can throw has a specific code that will not change between versions of Bugzilla.
The various errors that functions can throw are specified by the documentation of those functions.
If your code needs to know what error Bugzilla threw, use the numeric code. Don't try to parse the description, because that may change from version to version of Bugzilla.
Note that if you display the error to the user in an HTML program, make sure that you properly escape the error, as it will not be HTML-escaped.
If the error code is a number greater than 0, the error is considered "transient," which means that it was an error made by the user, not some problem with Bugzilla itself.
If the error code is a number less than 0, the error is "fatal," which means that it's some error in Bugzilla itself that probably requires administrative attention.
Negative numbers and positive numbers don't overlap. That is, if there's an error 302, there won't be an error -302.
Sometimes a function will throw an error that doesn't have a specific error code. In this case, the code will be -32000 if it's a "fatal" error, and 32000 if it's a "transient" error.
Many Webservice methods take similar arguments. Instead of re-writing the documentation for each method, we document the parameters here, once, and then refer back to this documentation from the individual methods where these parameters are used.
Many WebService methods return an array of structs with various fields in the structs. (For example, "get" in Bugzilla::WebService::Bug returns a list of bugs that have fields like id, summary, creation_time, etc.)
These parameters allow you to limit what fields are present in the structs, to possibly improve performance or save some bandwidth.
include_fields (array)An array of strings, representing the (case-sensitive) names of fields. Only the fields specified in this hash will be returned, the rest will not be included.
If you specify an empty array, then this function will return empty hashes.
Invalid field names are ignored.
Example:
User.get( ids => [1], include_fields => ['id', 'name'] )
would return something like:
{ users => [{ id => 1, name => '[email protected]' }] }
exclude_fields (array)An array of strings, representing the (case-sensitive) names of fields. The fields specified will not be included in the returned hashes.
If you specify all the fields, then this function will return empty hashes.
Invalid field names are ignored.
Specifying fields here overrides include_fields, so if you specify a field in both, it will be excluded, not included.
Example:
User.get( ids => [1], exclude_fields => ['name'] )
would return something like:
{ users => [{ id => 1, real_name => 'John Smith' }] }
Normally, XML-RPC does not allow empty values for int, double, or dateTime.iso8601 fields. Bugzilla does--it treats empty values as undef (called NULL or None in some programming languages).
Bugzilla also accepts an element called <nil>, as specified by the XML-RPC extension here: http://ontosys.com/xml-rpc/extensions.php, which is always considered to be undef, no matter what it contains.
Bugzilla does not use <nil> values in returned data, because currently most clients do not support <nil>. Instead, any fields with undef values will be stripped from the response completely. Therefore the client must handle the fact that some expected fields may not be returned.