Typically, an API proxy’s operation’s method should match the backend service’s HTTP method. Sometimes you might come across a scenario where the backend service that you are proxying supports an HTTP method that is different from what is exposed by your API proxy. A typical example is exposing a REST API (GET) method that proxies a SOAP backend service. It is common for SOAP services to be exposed via a POST method irrespective of whether they fetch the results (typically GET) or perform other updates (POST/PUT/DELETE). In such a case, you can use the HTTP Method property (Figure 4.25) of the Invoke policy to match the HTTP method that is supported by the backend service.
Figure 4.25 – Invoke policy’s HTTP Method property
You may be wondering about the Keep option. Keep is the default value and it means that the incoming HTTP method should be continued as the HTTP method to the backend service. You will learn more about these options in, Chapter 5, Modernizing SOAP Services.
Often there are strict requirements around the header and parameters that can be passed to the backend service. The Invoke policy provides a couple of properties that can be used to meet such requirements. You’ll see an example of this next.
Header Control and Parameter Control
The Header Control and Parameter Control properties control the request’s headers and parameters that get passed to the backend service.
Often, you will have a requirement to block certain header values from being passed to the backend service called by your Invoke policy, for example, blocking the API request’s X-IBM-Client-ID/X-IBM-Client-Secret values from being passed to the backend service. You can easily handle such a requirement using the Header Control property:
- Open the patient-information API in Designer. Open the Gateway tab | invoke Policy | Header Control property. Click Add blocklist as shown in Figure 4.26:
Figure 4.26 – Header Control
2. Add the value ^X-Environment$ to Blocklist. This instructs the gateway to copy all headers except for X-Environment to the target service.
3. Save and Publish your API.
4. Click on the Test tab to run your API. Add the following headers to the request (refer to Figure 4.27):
X-Environment header with a value of Skip Me
X-Book-Reader header with a value of Allow Me
`
Figure 4.27 – Adding new headers in the Test facility
5. Click Send to send the request. When the request completes, click on the Trace tab | Invoke policy | Advanced slider. Refer to Figure 4.28:
Figure 4.28 – Reviewing Trace for headers
This will allow you to see the entire flow from the initial request to the call to the backend and the resulting response.
6. Scroll through the output and expand the headers to look for your X-Environment and X-Book-Reader headers. Notice that all headers except for X-Environment are passed, including your X-Book-Reader header, to the target backend service as shown in Figure 4.29:
Figure 4.29 – Header omission verification
This example demonstrated the use of the header control property of the Invoke policy and how it can be used to block certain headers from being passed to a backend service. You can use the same method to filter or allow query parameters using the Parameter Control property of the Invoke policy.
Another important capability of the Invoke policy is its ability to utilize variables and properties inside its URL property. This allows for the dynamic building of the backend URL. You will review this capability through an example in the next section.