Thank you for your feedback.
Form temporarily unavailable. Please try again or contact to submit your comments.
  • Madrid
  • London
  • Kingston
  • Jakarta
  • Istanbul
  • Helsinki
  • Geneva
  • Store

Controlling request and response content type

Log in to subscribe to topics and get notified when content changes.

Controlling request and response content type

Control which content types are allowed in scripted REST API requests and responses.

You can set default values for the service using the Default supported request formats and Default supported response formats fields. These fields define acceptable values users can pass in the Content-Type and Accept request headers, respectively. If a requesting user specifies an Accept or Content-Type header not supported by the service or resource, the instance responds with an HTTP error code 406 or 415.

You can override these values for each resource using the Supported request formats and Supported response formats on the Scripted REST Resource form.
Note: The Supported request formats field appears only for PUT, POST, and PATCH resources.
You can use wildcard values when specifying valid content types.
  • To perform a single-character wildcard search, use the percent sign (%) character. This wildcard finds words that contain any one character in place the percent-sign-character. For example, to find words such as text or test, search for: te%t.
  • To perform a multiple-character wildcard search, use the asterisk (*) character. This wildcard finds words that contain zero or more characters in place of the asterisk-character. For example, to find words such as planned or placed, search for: pl*d.
Scripted REST web services support application/json, application/xml, and text/xml by default. User-defined custom content types (with json or xml subtypes) are also supported. For example, application/vnd.collection+json and application/vnd.adobe.xdp+xml are treated as JSON and XML, respectively.
Important: If the request body format is not of a json or xml subtype, use only the request body dataStream field to access the request body. Using request body data, dataString, nextEntry(), or hasNext() with a non-json or non-xml format results in a 500 error response.

If a REST service or resource accepts the application/x-www-form-urlencoded content-type, the urlencoded values provided in the request can be retrieved as a json map. These urlencoded key-value pairs can be supplied as query parameters, via the request body, or both, and are combined and stored in the request parameters. They can be accessed via the request.queryParams object.

For example, if your API is defined to accept the application/x-www-form-urlencoded content-type and your API is implemented as follows,
(function process(/*RESTAPIRequest*/ request, /*RESTAPIResponse*/ response) {


})(request, response);
… then the following request yields the respective response:
POST to localhost:8080/api/now/some_api/some_resource?name3=value3&name4=value4
{ "result":
    { "name4": [ "value4" ], "name3": [ "value3" ], "name2": [ "value2" ],
      "name1": [ "value1" ]

When sending a binary type in a response, you must set the response content type and write the binary stream directly using a RESTAPIResponseStream object. You can access this object by calling getStreamWriter() on the response object. For more information, seeRESTAPIResponse - Scoped, Global.