Similar to the starting steps that you took while creating a SOAP proxy earlier, go ahead and start your LTE environment, open API Designer, connect to your workspace, and connect to your LTE environment. After that, follow these steps:

1. In the Develop APIs and products tile of API Designer, go to Add | API. In the Select API type view, select From existing WSDL service (REST Proxy). Review the diagram displayed on the side of the Select API type view (Figure 5.10).

Figure 5.10 – REST proxy to SOAP service pattern

There are two main things to note. One is that requests received by API Gateway are RESTful in nature; that is, they will accept either JSON or XML payloads. Second, the requests going to the backend service are of the SOAP type. Click Next.

2. In the File upload view, upload the Account service definition that was downloaded and saved by you as part of the Technical requirements section. The system should validate the service definition and display a success message. Click Next.

3. In the Select Service view, Account service should be auto-selected for you as that is the only service defined in the service definition file. You will notice that there is only a single operation defined in this service. Compare this with the Calculator service, which had four operations (Add, Subtract, Multiply, Divide) defined in its WSDL file. Click Next.

4. In the Info section, review all the details that are populated by APIC. You can change Base path in this section. You can change the Base path value to /accounts. For now, accept the other default values and click Next.

5. In the Secure section, as done previously, unselect CORS and select Activate API. Click Next. You have now created your proxy API definition.

It is time to review the configuration that is generated by APIC to make this conversion between REST and SOAP possible. You are just going to observe how this differs compared to the SOAP proxy to SOAP service configuration.

Review the REST proxy configuration

The configuration of the newly created REST proxy is quite different from the SOAP proxy. This is obvious from the fact that our proxy is no longer a SOAP passthrough type. There are a number of extra actions that our proxy now performs:

• Message translation: It now consumes a JSON REST message instead of an XML SOAP message, and then does a JSON request translation to SOAP. It then performs the same actions in reverse, that is, a SOAP response coming from the backend service is translated to a JSON response sent to the proxy consumer.
• Support for multiple HTTP methods (GET and POST): It now supports a GET HTTP method along with a POST method. We will shortly see how it does that and all the configuration required to support these methods.

Through the next steps, you will now review the generated REST proxy and observe the important elements of its configuration:

1. Open your Proxy API in API Designer. Click on the API’s Design tab and then on the Paths section (in the left menu). Since there is only one operation defined in your WSDL, there is a single Path that is, /getBalance. You use this Path value while constructing your Proxy’s URL and use it for your Proxy testing.
2. In the Paths section, click on /getBalance and explore the Operations section. You will observe two HTTP methods, POST and GET.
3. Click on the GET operation. It is important to carefully go through the Path Parameters and Responses sections.

The Path Parameters section is where the request’s incoming parameters are defined. Incoming requests can contain data in query, path, header, form data, and body. You will see a single arg0 query parameter defined. This matches our simple service that only accepts one parameter, arg0, as part of the SOAP request body.

The Responses section is where the response schema is mapped to various HTTP status code values. The system has mapped HTTP 200 code to getBalanceResponse_element_tns schema and HTTP 500 to the CommonFault schema. It is important that you go through these schemas. You can review these schemas by going to the API’s Design tab and clicking on Definitions.

Navigate to the /getBalance Path | POST Operation. You will observe that the main difference (compared to the GET operation) is in the Path Parameters section. The POST operation’s Path Parameters contains a request parameter that is in the body of the request and its type is getBalance_element_tns. This is in line with the nature of the HTTP method. Data should now be sent in the request body instead of the query parameter (as was the case with the GET method request). There are no changes to the Responses section.

Having now reviewed the Paths configuration, let’s take a tour of the Gateway tab (Figure 5.11) of the generated Proxy. It is important to carefully review the Table 5.1. It will give you an in-depth understanding of the generated configuration that facilitates the mapping of a REST proxy to a backend SOAP service. You will immediately observe that this generated configuration is much different and more complex than the SOAP proxy configuration. The SOAP proxy configuration was a simple passthrough with no translation of schema or the protocol itself. On the other hand, the REST proxy needs to perform a schema translation from JSON/REST to XML/SOAP and a method translation from GET/POST (REST) to POST (SOAP), hence the complexity.

Figure 5.11 – Gateway tab of REST to SOAP Proxy

Table 5.1 – Policy details of the Account service

Tip

You can write conditions scripts in the Switch policy using JSONata functions, numeric operators, comparison operators, and functional expressions. This is applicable for API Gateway only. There are many expressions supported, such as $httpVerb() and $operationPath(). $httpVerb() that map to the request.verb context variable and $operationPath() that maps to the api.operation.path context variable.

You will see more examples of Switch condition scripts in Chapter 6, Supporting FHIR REST Services.

That was a great deal of insight into all the nut and bolts of proxy configuration generated for you by APIC. You can now try to expand on this information by changing this configuration to use Catalog Properties and redesigning the schema for proxy JSON responses. Catalog Properties are available in your API’s Gateway tab. As another learning exercise, you can generate a more complex configuration by using the Calculator service to generate a REST proxy. With all this learning behind you, it is time to test the REST proxy.