It is time to test the REST proxy. You will use the Test tab to test the REST endpoint. The endpoint will remain the same for GET and POST method invocations:

1. Go to your proxy Test tab.
2. Select the GET method URL in the URL selection drop-down box. You will notice that the testing facility has automatically populated various Parameters, such as Accept, APIm-Debug, and X-IBM-Client-Id. Refer to Figure 5.12.
3. Create a query parameter, arg0, in the same request and assign this parameter a value of 12345. Refer to Figure 5.12.
4. After you have done the required preparation, go ahead and Send the request. You should receive an HTTP 200 message and a valid response.

Figure 5.12 – GET request for the REST Proxy

5. You will test the POST method now. Change the Request URL to the POST method URL. Delete the arg0 query parameter from the Parameters tab. Construct a simple JSON request payload in the Body tab. Refer to Figure 5.13.

6. Click Send. You should receive an HTTP 200 message and a valid response. This test helped you to understand the method of testing a REST proxy, along with the method of passing the request data to a POST method of a REST proxy.

Figure 5.13 – POST request for REST Proxy

This section covered in detail the process of creating a simple REST proxy, configuring it, and testing it. You also reviewed the difference in complexity of REST proxy configuration and SOAP proxy configuration. Your configuration exploration took you into the depths of how the Path Parameters section is mapped to various incoming request attributes (query, headers, form data, body) and the ways of accessing those attributes in the Map policy of the Gateway tab.

Chapter 4, API Creation, and this chapter have given you a good overview of various development concepts of API development. They should have also laid a solid foundation for working with APIC LTE and API Designer. The next couple of chapters will build upon this foundation. Chapter 6, Supporting FHIR REST Services, will utilize the concepts covered so far to teach you how to build advanced FHIR (an extremely important healthcare interoperability standard) services. Chapter 7, Securing APIs, will cover one of the most important aspects of software development, and that is security. But before we take on those advanced concepts, let’s wind up this chapter with a short summary.

Summary

The focus of this chapter was to cover in detail two different methods of modernizing your SOAP-based legacy assets. Method one was about exposing these assets via a SOAP proxy. Method two was about exposing them as a REST proxy. The techniques discussed in this chapter helped you quickly expand your company’s API repository while making it easier for your existing customers to make use of your SOAP-based business functionality.

There are other legacy assets or non-SOAP assets that can be modernized too. These non-SOAP assets could be your messaging infrastructure (MQ) or your databases. You can use advanced APIC policies such as the GatewayScript policy to make connections to your backend servers.

Though it is now easier, with all the tools and flexibility at our disposable, to create APIs, the question that you should answer before embarking on your API’fication is if the functionality that you intend to make available as an API is even qualified to be one. API candidates (only from a modernization perspective) should be carefully weighed. Each organization builds their own API candidate selection criteria. Some common ones worth mentioning are the reusability score, granularity of business function, and consumer maturity index. Not all integration modernization problems can be solved using an API.

Make sure you remember Maslow’s hammer:

“I suppose it is tempting, if the only tool you have is a hammer, to treat everything as if were a nail.”

APIC is most definitely a hammer, but not everything is a nail. Use the hammer judiciously!

In the next chapter, we will see how to develop REST APIs that support FHIR.