The previous section was about understanding the API’s grammar. This section will be about building the sentences and starting to put those grammar rules into practice. You will do that by creating an API Proxy using Designer and then test that on the LTE. It is worth mentioning that you can follow the steps provided in this section on the API Manager interface as well. Steps on the API Manager are quite similar to the steps provided for the LTE environment.
Prerequisites
- Make sure that you have Designer and the LTE installed and configured on your workstation.
- Ensure that you can access the https://stu3.test.pyrohealth.net/fhir/Patient/d75f81b6-66bc-4fc8-b2b4-0d193a1a92e0 resource from your workstation. The API Proxy that you will soon build uses this backend service URL.
API development
It is time for you to start with the API development:
- On the Designer’s home screen, click on the Develop APIs and products tile. Click Add | API (from REST, GraphQL or SOAP).
- Stay on the default OpenAPI 2.0 tab.
- Notice the various API types (Figure 4.9) that can be created. You will learn how to implement the SOAP Proxy and REST proxy using a WSDL file in Chapter 5, Modernizing SOAP Services. In Chapter 9, Building a GraphQL API, you will learn how to create a GraphQL proxy.
You will be creating your first API utilizing an existing target service.
In the Select API type view, select the From target service option and click the Next button.
Figure 4.9 – API types
4. In the Info section, specify the following information (Table 4.2):
Table 4.2 – Info section values for the new API
5. Click the Next button. In the Secure section, keep the options of Secure using Client ID and CORS selected.
6. Click the Next button, where APIC will display the summary of the API generation process.
7. Click the Edit API button to further configure your API definition.
8. Review the various sections (General, Paths, Definitions, and so on) under the Design tab (Figure 4.10).
Figure 4.10 – Design tab user interface
Figure 4.10 shows how APIC has organized OAS under various key sections. By clicking on each section of the Design tab and reviewing various parameters of each section, you will see how easy APIC makes it to create the OAS source, instead of typing it all into a file. Of course, you can click on the source view icon to review the OAS in a file format. As you click through the various sections under the Design tab, take time to correlate much of the information in these sections (General | Info, General | Schemes List, General | Security, Paths) with the OAS that you learned about in the OpenAPI design section of this chapter.
APIC provides comprehensive security coverage for APIs. As was discussed earlier, in the OpenAPI design section of this chapter, APIC supports multiple security schemes. You will be getting a comprehensive tour of APIC’s API security features in Chapter 7, Securing APIs. For now, you will keep it simple and secure your API using the API key security scheme. Go ahead and review the security definitions of your API. Go to the Design tab | Security Schemes section. You will note that it already has an apiKey with the name clientID. This was created because you kept the option of Secure using Client ID selected in the earlier step. Go ahead and further strengthen your API’s security by adding a definition for the client_secret type apiKey.
9. Click the Plus icon next to the Security Schemes menu item. Provide the values highlighted in Figure 4.11. Once complete, click on Save.
Figure 4.11 – client_secret apiKey
Note
The X-IBM-Client-Id and X-IBM-Client-Secret header names are not APIC specific. You can substitute these with any other names, for example, X-ABC-Client-Id or X-ABC-Client-Secret. It is still a good practice to use the standardized names of X-IBM-Client-Id and X-IBM-Client-Secret.