REST Endpoints
Representational State Transfer (REST) endpoint is a URL that runs a script. REST endpoints are configured programmatically. You can define REST endpoints in ScriptRunner, for example, to:
Use in dashboard gadgets.
Receive notifications from external systems.
Plug gaps in the official REST API.
Allow all your XHRs to proxy through to other systems.
Adding a REST Endpoint
Follow this task to create a custom REST endpoint:
Select the Cog icon, and then select General Configuration.
Scroll to the ScriptRunner section in the left-hand navigation, and then select REST Endpoints.
Select Add a New Item, and then select the Custom Endpoint
Use the following REST endpoint example to examine the different parts of the script:
Line 8: This line makes methods in your script recognizable as endpoints, which is required.
Line 10: The name of the REST endpoint, which forms part of the URL. In this example, it is doSomething
.
Line 11: This line configures the endpoint and determines which HTTP verb to handle and what groups to allow.
Line 12: This line contains parameters that are provided to your method body.
Line 13: The body of your method, where you will return a javax.ws.rs.core.Response
object.
You can add this REST endpoint to the list of configured endpoints as an inline script or by copying into a file and adding that file as a script file. To test this endpoint, type this text into your browser:
Notice the last part of the text is the name doSomething.
<bamboo_base_url>/rest/scriptrunner/latest/custom/doSomething
Alternatively, you could type this into the command line utility:
Again, notice the name
doSomething
in each command.admin:admin
corresponds to a username and password.
curl -u admin:admin <bamboo_base_url>/rest/scriptrunner/latest/custom/doSomething
{"abc":42}
If you are using a file, you can change the response. You may need to select the Scan button on the REST Endpoints page before calls to the endpoint return the new response. See the section on Script Root Scanning below.
Configuration
The general format of a method defining a REST endpoint is:
groovymethodName (Map configuration, Closure closure)
For the configuration, only the following options are supported:
Key | Value |
---|---|
httpMethod | Choose one of: |
groups | One or more groups. If the requesting user is in any of the groups, the request is allowed. |
Either or both of these can be omitted. If you omit the groups attribute, the endpoint will be available to unauthenticated users.
Use these parameters for the closure:
Parameter | Type | Description |
---|---|---|
queryParams | This corresponds to the URL parameters. | |
| Content | This is the body of the request for |
Request | This returns the requesting user for the instance. |
You can use any of these forms for your closure:
something() { MultivaluedMap queryParams ->
something() { MultivaluedMap queryParams, String body ->
something() { MultivaluedMap queryParams, String body, HttpServletRequest request ->
something() { MultivaluedMap queryParams, HttpServletRequest request->
The contents of your closure depends on what you need access to.
Where the closure signature contains the body
variable, the request input stream is read before your closure is executed, and the read data is passed to the closure in the body
.
The request input stream can only be read once. If you want to avoid the request input stream from being read before your code executes, for instance if you are reading file uploads, use the final form of the closure:
groovysomething() { MultivaluedMap queryParams, HttpServletRequest request->
Access Request URL
Sometimes you may need to use the URL path after your method name. In the following example, you want to retrieve /foo/bar
:
groovy<base_url>/rest/scriptrunner/latest/custom/doSomething/foo/bar
Use the 3-parameter form of the closure definition and call the getAdditionalPath
method from the base class.
For example:
groovydoSomething() { MultivaluedMap queryParams, String body, HttpServletRequest request -> def extraPath = getAdditionalPath(request) // extraPath will contain /foo/bar when called as above }
In previous versions, an extraPath
variable was used in the scripts. However, this is not thread-safe. Use the method above.
Script Root Scanning
As well as manually adding scripts or files via the UI, ScriptRunner scans your script roots for scripts that contain REST endpoints and automatically register them. To enable the scanning, set the property plugin.rest.scripts.package
to a comma-delimited list of packages. For example:
groovy-Dplugin.rest.scripts.package=com.acme.rest
On plugin enablement, scripts/classes under this package are scanned and registered if the scripts contain the following line:
groovy@BaseScript CustomEndpointDelegate delegate
Package Declarations and File Paths
Your REST Endpoint's code must begin with a package declaration that matches the package configured in the system property. Likewise, the file path in your script root must match that package declaration as well.
For example, if your plugin.rest.scripts.package
system property is com.acme.rest
and you want to create a custom REST Endpoint with a file named MyCustomRestEndpoint.groovy, then:
- The first line of the MyCustomRestEndpoint.groovy file should be
package com.acme.rest
. - The file should have a line like
@BaseScript CustomEndpointDelegate delegate
as normal. - The path to the file within your script root should be com/acme/rest/MyCustomRestEndpoint.groovy .
Subpackages should be okay, so long as the sub-directory matches the package. For example, you might put the file in com/acme/rest/widgets
so long as your package declaration is com.acme.rest.widgets
in the top line of the file.
If you are receiving unexpected HTTP 500 errors when trying to access your REST Endpoints that were added through Script Root Scanning, check your package declaration. Case sensitivity may be an issue as well, depending on your filesystem.