Bugzilla::WebService::Server::JSONRPC - The JSON-RPC Interface to Bugzilla
This documentation describes things about the Bugzilla WebService that are specific to JSON-RPC. For a general overview of the Bugzilla WebServices, see Bugzilla::WebService.
Please note that everything about this JSON-RPC interface is UNSTABLE.
If you want a stable API,
please use the XML-RPC|Bugzilla::WebService::Server::XMLRPC
interface.
Bugzilla supports both JSON-RPC 1.0 and 1.1. We recommend that you use JSON-RPC 1.0 instead of 1.1, though, because 1.1 is deprecated.
At some point in the future, Bugzilla may also support JSON-RPC 2.0.
The JSON-RPC standards are described at http://json-rpc.org/.
The endpoint for the JSON-RPC interface is the jsonrpc.cgi
script in your Bugzilla installation.
For example,
if your Bugzilla is at bugzilla.yourdomain.com
,
then your JSON-RPC client would access the API via: http://bugzilla.yourdomain.com/jsonrpc.cgi
Bugzilla only allows JSON-RPC requests over POST
.
GET
requests (or any other type of request,
such as HEAD
) will be denied.
For JSON-RPC 1.0,
the very first parameter should be an object containing the named parameters.
For example,
if you were passing two named parameters,
one called foo
and the other called bar
,
the params
element of your JSON-RPC call would look like:
"params": [{ "foo": 1, "bar": "something" }]
For JSON-RPC 1.1, you can pass parameters either in the above fashion or using the standard named-parameters mechanism of JSON-RPC 1.1.
dateTime
fields are represented as an integer number of microseconds since the Unix epoch (January 1, 1970 UTC). They are always in the UTC timezone.
All other types are standard JSON types.
All errors thrown by Bugzilla itself have 100000 added to their numeric code. So, if the documentation says that an error is 302
, then it will be 100302
when it is thrown via JSON-RPC.
Errors less than 100000 are errors thrown by the JSON-RPC library that Bugzilla uses, not by Bugzilla.