REST Adapter Restrictions

Note the following REST Adapter restrictions.

If the endpoint response doesn't include a content-type or if the content-type is set to empty (""), the stream reference is not included in the response payload.
For this use case to succeed, the REST endpoint provider must update their service to return the correct content-type in the response header.
Transport Layer Security (TLS) version 1.3 is not supported.
REST endpoints can be protected using two-way SSL or mutual TLS authentication (mTLS). The REST Adapter supports accessing these endpoints. Authorization endpoints that procure and manage OAuth access tokens are also REST endpoints. However, these endpoints are not certified for use with the REST Adapter connection when protected using two-way SSL.
Two-way SSL is not supported for calls to external services through the connectivity agent. Two-way SSL requires direct connectivity from Oracle Integration without the connectivity agent.
The maximum permissible limit for JSON file samples is 100 KB.
Plain/text content-type can be sent or received as unparsed content by the REST Adapter using the raw payload option.
Consuming external REST APIs that are protected using NTLM or digest token-based authentication are not supported.
When configuring the REST Adapter to work with the on-premises connectivity agent on the Connections page, only the Basic Authentication, OAuth Client Credentials, OAuth Resource Owner Password Credentials, OAuth Custom Two Legged Flow, and No Security Policy security policies in the Security Policy list are supported.
The following security policies in the Security Policy list are not supported for use with the connectivity agent:
- AWS Signature Version 4
- OAuth Authorization Code Credentials
- OAuth Custom Three Legged Flow
- API Key Based Authentication
- OAuth 1.0 One Legged Authentication
- OCI Signature Version 1
See On-Premises REST API Support with the Agent.
The REST Adapter automatically encodes the value of query parameters before invoking a service. The REST Adapter has no way of knowing if you have already encoded a query parameter. Ensure that you assign unencoded values to query parameters. Assigning encoded values leads to double encoding.

For example, assume query parameter q has the following value:
```
q=a+b
```
This may mean that the value of q was intended to be a b, but was encoded by the user.

The intention may also have been to send a+b, which must be URL-encoded as a%2Bb before sending.
Polymorphic constructs are not supported when publishing OpenAPIs.
Unicode characters in the range of \u0000 to \u001F are control characters and are not allowed in JSON elements.
You can customize the response status. However, this is not shown as part of the Swagger contract because runtime overrides are not known as part of the interface.
HTTP response status cannot be customized under the following conditions:
- If the request is asynchronous one way. This is because the response status is always 201.
- Errors that occur during trigger request/response handling are reported using a predefined error code.
- Basic routing integrations (map my data integrations) don't allow fault handling and error responses in such scenarios.
- If the HTTP response status is set to 204, the response is sent back without any content.
If you use the OAuth 1.0 One Legged Authentication security policy for integrations with Oracle NetSuite, the default HMAC-SHA1 signature encryption algorithm that is automatically used is no longer supported starting with the May 2021 release of Oracle Integration. You must update your REST Adapter connections for integrations with Oracle NetSuite to use HMAC-SHA256. After making the update, integration reactivation is not required. See Configure Connection Security.

Note:

There are overall service limits for Oracle Integration. A service limit is the quota or allowance set on a resource. See Service Limits.

Swagger/OpenAPI Restrictions

Not all Swagger constructs are understood by the REST Adapter. Note the following limitations when publishing and consuming Swagger/OpenAPI.

Publish Restrictions

Note the following publish restrictions for the REST Adapter.

Polymorphic constructs are not supported when publishing OpenAPIs.
Endpoints created using REST Adapter trigger connections are described using a Swagger and openAPI definition. REST endpoints having an XML request/response are not correctly described. Clients must not rely on the Swagger/openAPI definition.
Each REST Adapter trigger connection endpoint is published as a Swagger document. The Swagger document usually has a single resource and verb.
However, in the case of multiple verbs and resources, the Swagger document has multiple resources or paths in Swagger and multiple verbs for each resource.
While OpenAPI lets you define dictionaries types where the keys are strings, dictionary types are not supported in Oracle Integration.
Only JSON payload is supported for publishing. XML payload is not supported.

Consume Restrictions

The REST Adapter as a client can be configured with a Swagger definition based on which it can discover and list the existing resource. However, some Swagger operations cannot currently be correctly consumed by the REST Adapter:

Only three multipart combinations are supported for consumption:
- One or many file upload body parts and any number of plain text fields using multipart/form-data
- One or many file upload body parts and one JSON body part using multipart/form-data
- One or many file upload body parts and one JSON body part using multipart/mixed
Content of JSON must be an object
XML
Top-level array
Raw/application/octet-stream
External REST APIs that are described using OpenAPI 3.0
Swagger documents of external REST APIs that have metadata regarding content types such as multipart/form-data, multipart/mixed, and application/octet-stream
REST Adapter invoke connections cannot consume Swagger documents with recurring nested structures. For example:
```
Employee &#8594; payroll &#8594; item (line 1, line2)
Manager &#8594; payroll  &#8594; item (line 3, line4)
```
In such a case, the Swagger parser caches the first definition of item and uses that causing incorrect manager schema. This issue is addressed, but the fix is currently not enabled due to backward compatibility.

REST endpoints that do not have a request or a response cannot be consumed using a Swagger-based connection or using the local integration. If an error appears after initializing the local integration or the Adapter Endpoint Configuration Wizard with a Swagger-based connection, check the limitations on consumption of certain Swaggers.

Note these additional restrictions:

The missing server URL for the OpenAPI specification is resolved from the OpenAPI host port. If the server URL is missing from the OpenAPI specification, the base URL is resolved from the domain/host:port of the OpenAPI URL where the OpenAPI specification is hosted. For an example, the target endpoint is resolved using the host and port where the OpenAPI specification is hosted as follows:
```
http(s)://host:port/path-from-openapi
```
Headers/custom headers must be added manually and are not discovered from the OpenAPI specification.
Connectivity agent limitations:
- Swagger API consumption does not work with the connectivity agent.
- OpenAPI consumption does not work with the connectivity agent.
If a Swagger or OpenAPI specification defines multiple success responses, Oracle Integration uses the responses based upon the following criteria:
- Oracle Integration first looks for a success response (200).
- If the definition does not contain a 200 response, Oracle Integration looks for a response definition with default.
- If default is not defined, Oracle Integration looks for a response with a 201 definition.
In each category, Oracle Integration first uses the response corresponding to application/json. Otherwise, Oracle Integration uses the first response in the list of responses for the status code.