By default, REST based integration flows return the following HTTP response status:
- HTTP 200 (OK) in case of success
- HTTP 202 (Accepted) in case of Asynchronous flows.
- HTTP 4xx in case of client side errors like calling the integration flow with the wrong method or URL etc.
- HHTP 5xx or user-defined in case of failures during the integration flow but with a fixed error format.
The integration developer needs to assign the HTTP response status code from the mapper as follows:
This option provides a number of possibilities to integration developers, few applications of which are:
1. Return a redirect (3xx) code.
- There exist several re-direct codes that have specific meaning. For instance method forwarding is usually performed by some clients only when the status code is 307. While in some cases a POST is always redirected as a GET (PRG) to avoid double posts.
When a web form is submitted to a server through an HTTP POST request, attempts to refresh the server response can cause the contents of the original POST to be resubmitted, possibly causing undesired results, such as a duplicate insert.
To avoid this problem, using the PRG pattern, instead of returning a 2xx, the POST returns a redirect. The HTTP 1.1 specification introduced the HTTP 303 ("See other") response code to ensure that in this situation, browsers can safely refresh the server response without causing the initial POST request to be resubmitted.
2. Asynchronous request/reply integration pattern
- The client submits a job by sending a request and receives an HTTP 202 (Accepted) response along with the location header pointing to the status endpoint.
- The client keeps checking the status by sending an HTTP GET request to the status endpoint. The work is still pending, so this call also returns HTTP 202.
- At some point, the work is complete and the status endpoint returns 302 (Found) redirecting to the resource as the location header.
- The client fetches the resource at the specified URL.
3. Send a customized error response
OIC allows REST based integrations to return a fault with a user defined http error status as mentioned in this blog post. The error format however is always fixed to APIInvocationError.
By overriding the default Http response code, the actual response can be sent back as an error response by the integration developer.
In summary, we explored how the option to override http response code can help unlock interesting patterns of integration in Oracle Integration Cloud. What we have illustrated are a few but there are many more such possibilities.