The steps discussed in this chapter are built upon the installation of the APIC Designer and APIC LTE environment covered in Chapter 4, API Creation. They also use two publicly available SOAP services: the Calculator service (used for building a SOAP API proxy) and the Account service (used for building a REST API proxy). You should ensure the following:

• Access to these services is not blocked by your machine’s firewall or corporate network. The service endpoints are as follows:
  • Calculator service: http://www.dneonline.com/calculator.asmx
  • Account service: https://apictutorials.mybluemix.net/AccountService
• Service definitions (WSDL files) for these services are downloaded to your local workstation. You can download service definitions from the following URLs:
  • Calculator service: http://www.dneonline.com/calculator.asmx?wsdl
  • Account service: https://www.ibm.com/support/knowledgecenter/SSMNED_v10/com.ibm.apic.apionprem.doc/AccountServicing.txt?view=kc

You can test these services using a SOAP testing tool such as SoapUI. Go ahead and import these WSDL files in SoapUI and send example requests. Your results should look like Figure 5.1 and Figure 5.2.

Figure 5.1 – Example test case for the Calculator service

And here is the output for the Account service:

Figure 5.2 – Example test case for the Account service

Before we go into building SOAP and REST API proxies on top of our simple Calculator SOAP service, let’s discuss the support for the SOAP protocol in APIC V10.

SOAP capabilities in APIC

APIC supports exposing existing SOAP services as either SOAP or REST proxy APIs. The basic requirement for the services to be exposed is that those services should support Web Services Basic Profile 1.1 – Second Edition.

To create a SOAP API definition, you will need access to an existing SOAP web service. This existing web service can have a WSDL that can be defined either by a single standalone WSDL (we will be using this in our examples) or by a WSDL file that references other WSDL files and/or schemas.

Note

For standalone services definitions that have no external dependencies, such WSDLs can be directly loaded from a directory to create the SOAP API definition.

For service definitions that have dependencies on other WSDLs and schemas, you will need to create a ZIP archive of the main service definition and all its dependencies and then load the ZIP file to create the SOAP API definition.

APIC provides API generation patterns that take care of generating either SOAP or REST API proxies from a provided SOAP service definition (standalone or otherwise). You will cover how to use these patterns and techniques to generate SOAP/REST API proxies in the following sections, starting with generating a SOAP API proxy from an existing SOAP service. But before deep diving into a couple of these patterns, let’s quickly look at all the proxy patterns supported by APIC v10. To do that, log in to your API Designer and after performing the initial steps of selecting your workspace and logging into your LTE cloud environment with shavon/7iron-hide credentials, go ahead and Add a new API. Your screen should look like Figure 5.3.

Let’s take a quick walk-through of the Select API type landscape and all the options that are made available by APIC here. We will stay with the Open API 2.0 tab for now.

Figure 5.3 – API creation patterns

As is apparent, there are a number of options made available by APIC to accommodate various API patterns. Let’s take a quick overview of some of the important ones before we go into discussing a couple of them in detail:

• From target service: Use this to build an API proxy definition from the ground up. The most common use case is when you have a target service URL available, and it is to be exposed through a custom schema that is different from the schema exposed by the target service. The target service could be a REST, SOAP, MQ, or database endpoint. This option is most suitable when custom processing logic needs to be applied before invoking the target service and/or the target service is not described by a standardized schema.
• From existing OpenAPI service: Use this to expose an OpenAPI-based REST service. You can import an existing YAML, JSON, or XML OpenAPI definition. Of course, you will still be building the API proxy implementation using various policies and other constructs in the Gateway tab. This pattern is most often used to proxy target services that have a defined OpenAPI definition, which is mostly the case with mature service organizations.
• From existing WSDL service (SOAP proxy) and From existing WSDL service (REST proxy): Use this to expose a SOAP service as a SOAP or REST proxy. As discussed at the beginning of this chapter, this is the primary focus of service modernization exercises, that is, to use an existing SOAP-based asset and make it available to consumers as either a REST API proxy or a SOAP API proxy. We will be discussing this in detail in the following two sections of this chapter.
• From existing GraphQL service (GraphQL proxy): You will learn about this in detail in Chapter 9, Building a GraphQL API.
• New OpenAPI: You use this to create a draft API definition. Note that this draft definition does not have any target service attached to it. It is simply a definition and requires configuring any associated Policies and target services. Depending upon what tool is used to create the API definition, the definition is either stored on the management server (if API Manager is used) or the workspace directory specified when you logged into API Designer.

Note

The From target service, From existing OpenAPI service, and New OpenAPI options are available for both OpenAPI 2.0 and OpenAPI 3.0 Proxy types.

For the From existing OpenAPI service option, you can only create an OpenAPI 2.0 proxy if your target OpenAPI is described by OpenAPI 2.0 specification. Similarly, you will only be able to create an OpenAPI 3.0 proxy if your target OpenAPI is described by an OpenAPI 3.0 specification. Creating an OpenAPI 2.0 proxy using an OpenAPI 3.0 specification or vice versa is not permitted. You can experiment with various example definitions at https://github.com/OAI/OpenAPI-Specification/tree/master/examples.

Now that we have explored the various API proxy patterns available in APIC, it is time to look at the patterns that will help us in our service modernization efforts. You will soon appreciate the ease with which APIC helps us proxy our SOAP-based services either as a SOAP or REST proxy.