Designer 10.7 | webMethods Service Development Help | Working with REST API Descriptors | OpenAPI-Based Provider REST API Descriptors | Working with Resources | Working with Operations | About REST Requests
 
About REST Requests
When you select Request for an operation, Designer displays the input parameters in the REST V2 resource service that corresponds to the operation and the request body details.
REST request parameters and request body details
Parameters
When you select Parameters under Request, for each parameter, Designer displays the following information:
*Name: Matches the name of the input parameter in the corresponding service.
*Type: Specifies the data type of the parameter.
*Source: Indicates the source of the parameters in the incoming request. The source corresponds to the in field of the parameter object as defined by the OpenAPI Specification 3.0.x. A parameter can have one of the following source values:
*PATH
*QUERY
*HEADER
*COOKIE
Note: 
*When an OpenAPI document contains PATH parameters with style label, ensure that the parameter values do not contain a dot (".") character in the URL while sending a REST request; otherwise the request might fail.
*Integration Server does not support AllowEmptyValues attribute configured for the parameters in the OpenAPI document because the OpenAPI specification deprecates this attribute from future versions.
*For the object type query parameters having form style and explode set to true, Integration Server maps the parameter values to all the query variables in the input service signature.
*For query parameters, Integration Server sets the additional property values as a string in the input pipeline.
*If a query parameter value contains a percent (%) character, convert the character into an URL encoded form.
*Required: Indicates whether or not the parameter is required in the input. Designer obtains this value from the Required property for the parameter in the corresponding REST V2 resource service.
You can also click to view the additional parameter details, for example, Media type, Style, Extensions, and Constraints.
Request Body
The body of the REST requests lists the media types consumed by the operation, for example, application/json and specifies the schema for each media type. Designer displays the following details for the REST request:
*Name: Specifies the media type.
*Type: Specifies the data type.
*Constraints: Indicates the composed keywords used to validate the schema for the request body. Designer can use one or more of the following supported constraints to validate schemas as per OpenAPI Specification 3.0.x.
*oneOf: Validates a value against exactly one of the subschemas.
*allOf: Validates a value against all the subschemas.
*anyOf: Validates a value against any (one or more) of the subschemas.
*not: Ensures that the value is not valid against a specified schema.
When Integration Server receives data in a REST request and needs to validate it against a not keyword, and the data can be interpreted as multiple primitive data types, then Integration Server converts data type into a default data type and validates it. For example, consider a schema that defines a not keyword as:
not:
type: integer
format: int32
If Integration Server receives a value of 100 for this schema, which can be interpreted as a java.lang.Integer (int32) or java.lang.Long (int64), by default, Integration Server converts the value into a java.lang.Long type and validates it. Because Integration Server is validating the value against a not keyword, the validation passes. However, if the schema defines the not keyword as:
not:
type: integer
format: int64
when Integration Server is validating a value of 100 against this schema, the validation fails because the type of the converted data is the same as the type defined in the schema (int64).
*Required: Indicates whether or not the request body is required in the input. Designer obtains this value from the Required property for the request body.