Classic REST will make use of URI to define object values in the path and/or query parameters as well. This means that ICS has to provide a means by which the URI can be processed to extract values; for example, https://mywebService.com/products/101/ could be used to refer to products identified by an ID of 101. In proper REST service terms this would return the details of product 101, but if we want to query all products for those containing oil you might have a URI like https://mywebService.com/products/?contains=oil, so you need to be able to link possible query values. In our case, we do not need any parameters or attribute related details in the URI.

Before we move onto the next tab, let's address two considerations that you may wish to use in the future - the use of headers and CORS. The use of HTTP headers was referenced in Chapter 1, Introducing the Concepts and Terminology and Chapter 2, Integrating Our First Two Applications. The HTTP header normally carries a number of standard parameters that describe the nature of the HTTP payload and its delivery as name value pairs. Best practice points to using custom header attributes for informational purposes only; for example, the data in a HTTP body originates from a web cache. Many of the additional header attributes have become de-facto standards, for example, pingback addresses for WordPress.

Cross-Origin Resource Sharing (CORS), like HTTP, CORS has originated from the W3C to help address the problem where if a website then wants to exploit resources from a different website where these websites have different domains, (for example, www.myWebsite.com and www.google.com) as many of the HTTP API functions used by things such as JavaScript (for example, XMLHttpRequest, which is used by AJAX calls) are restricted calls within their own domain - for example, my web application provided by www.MyWebsite.com would not be allowed to call www.google.com/API/GetSomeData. This restriction is to mitigate against Cross Site Scripting attacks. The CORS standard, which is now realized by all recent browser versions, addresses this by working through an agreed set of types of interaction or through an agreed handshake protocol. The use of CORS when the handshake approach is used is done primarily through header attributes. The tick box provided by ICS provides the means to configure these headers.

Having explored these other areas a bit more, we can move to the next tab using the Next button.

Having provided the details of the first tab, which informs how the remaining tabs will appear, we can start on the request information by completing the details as shown in the following table:

Coming back to the payload request, we can provide our payload sample by using the file selector or paste it in for ICS to see. The file selection is no different to selecting a WSDL or any other file we have seen so far. We are going to choose the <<< inline >>> option. Click on <<< inline >>> to get a new screen displayed, as you can see in the following screenshot:

The JSON payload for the request has already been created and can be found with the other chapter resources, in a file called ICSBook-Ch7-FlightProgress-Source-request.json. The content of this file needs to be just pasted into the form. If the JSON within the form is incorrect, Oracle will alert you to this fact. The JSON content provided is valid, but by editing it you can see the validation fail the payload easily. With the valid JSON loaded, we can complete the dialog by clicking on the OK button. Then we need to move on to the next part of the configuration by clicking on the Next button. As we have chosen not to do anything with regards to the Request Header or CORS, this will take us into completing the details defining the response payload. The following table provides the details to complete this:

Once the response details have been provided we can move on again with a click of the Next button. As we are not changing the Response Headers either, we will move onto the summary stage. The REST endpoint summary is like any other endpoint summary, so we can complete the process by clicking on the Done button.

As we have replaced the source, we will need to reapply the mappings; the details are given in the following table:

As with our original filter, we want to set the notes field on the target side to be a literal value, but this time the value should be JSON source. This will mean we can differentiate the call between the two integrations to the common Mockable.io endpoint. With that, the flow to FilteredFlightProgress mapping is complete and we can use the Save and Exit Mapper buttons.

We also need to reapply the executeResponse flow, with the mapping values given in the following table:

We should also apply the same approach to the value for the target notified element where the notified element from FilteredFlightProgressResponse is prefixed using the string concat function with the literal value of JSON response is. The mapping should look something like:

Again, save the mapping and exit. This just leaves applying the filter again.