You may choose a specific API version by appending the /rest/api/VERSION string to the URLs path. Its more common to left it unspecified, in which case the /rest/api/latest string is appended automatically to the URL.
The username of a JIRA user.
It can be undefined if PASSWORD is also undefined. In such a case the user credentials are looked up in the .netrc file.
The HTTP password of the user. (This is the password the user uses to log in to JIRAs web interface.)
It can be undefined, in which case the user credentials are looked up in the .netrc file.
A JIRA::REST object uses a REST::Client object to make the REST invocations. This optional argument must be a hash-ref that can be fed to the REST::Client constructor. Note that the URL argument overwrites any value associated with the host key in this hash.
To use a network proxy please set the proxy argument to the string or URI object describing the fully qualified (including port) URL to your network proxy. This is an extension to the REST::Client configuration and will be removed from the hash before passing it on to the REST::Client constructor.
JIRAs REST API documentation lists dozens of resources which can be operated via the standard HTTP requests: GET, DELETE, PUT, and POST. JIRA::REST objects implement four methods called GET, DELETE, PUT, and POST to make it easier to invoke and get results from JIRAs REST endpoints.
All four methods need two arguments:
The PUT and POST methods accept two more arguments:
This is the resources path, minus the API version prefix. For example, in order to GET the list of all fields, you must pass simply /field, not /rest/api/latest/field, and in order to get a list of all the components of a project, you must pass simply /project/$key/components, not /rest/api/latest/project/$key/components.
This argument is required.
Some resource methods require or admit parameters which are passed as a query-string appended to the resources path. You may construct the query string and append it to the RESOURCE argument yourself, but its easier and safer to pass the arguments in a hash. This way the query string is constructed for you and its values are properly percent-encoded <http://en.wikipedia.org/wiki/Percent-encoding> to avoid errors.
All four methods return the value returned by the associated resources method, as specified in the documentation, decoded according to its content type as follows:
This is the entity being PUT or POSTed. It can be any value, but usually is a hash-ref. The value is encoded as a JSON <http://www.json.org/> string using the JSON::encode method and sent with a Content-Type of application/json.
Its usually easy to infer from the JIRA REST API documentation which kind of value you should pass to each resource.
This argument is required.
This optional argument allows you to specify extra HTTP headers that should be sent with the request. Each header is specified as a key/value pair in a hash.
Some endpoints dont return anything. In those cases, the methods return undef. The methods croak if they get any other type of values in return.
o application/json o text/plain
Those values are returned as simple strings.
In case of errors (i.e., if the underlying HTTP method return an error code different from 2xx) the methods croak with a multi-line string like this:
ERROR: <CODE> - <MESSAGE> <CONTENT-TYPE> <CONTENT>
Returns the RESOURCE as a Perl data structure.
Deletes the RESOURCE.
Creates RESOURCE based on VALUE.
Updates RESOURCE based on VALUE.
This module provides a few utility methods.
set_search_iterator PARAMSSets up an iterator for the search specified by the hash-ref PARAMS. It must be called before calls to <B>next_issueB>.
PARAMS must conform with the query parameters allowed for the /rest/api/2/search JIRA REST endpoint.
next_issueThis must be called after a call to <B>set_search_iteratorB>. Each call returns a reference to the next issue from the filter. When there are no more issues it returns undef.
Using the set_search_iterator/next_issue utility methods you can iterate through large sets of issues without worrying about the startAt/total/offset attributes in the response from the /search REST endpoint. These methods implement the paging algorithm needed to work with those attributes.
attach_files ISSUE FILE...The /issue/KEY/attachments REST endpoint, used to attach files to issues, requires a specific content type encoding which is difficult to come up with just the REST::Client interface. This utility method offers an easier interface to attach files to issues.
JIRA::REST uses a REST::Client object to perform the low-level interactions.
o JIRA::Client o JIRA::Client::REST
This is another module implementing JIRAs REST API using SPORE <https://github.com/SPORE/specifications/blob/master/spore_description.pod>. I got a message from the author saying that he doesnt intend to keep it going.
Gustavo L. de M. Chaves <email@example.com>
This software is copyright (c) 2016 by CPqD <www.cpqd.com.br>.
This is free software; you can redistribute it and/or modify it under the same terms as the Perl 5 programming language system itself.
|perl v5.20.3||JIRA::REST (3)||2016-01-16|