It is time to test the API Proxy. Here’s how:
- While still on the Test tab in Figure 4.14, click Send. You should now receive an HTTP 200 successful response with the associated payload displayed in the Response section. That is shown in Figure 4.15:
Figure 4.15 – HTTP 200 response with payload
2. You can click on the Headers tab to see the header used or the Trace tab to see the tracing of your policies. In this case, you only had the invoke policy, but in future cases, you will be able to see how APIC traverses through multiple policies.
You have completed the testing of your API Proxy. That was easy.
Note
The test capability you just completed only works on the DataPower API gateway service. This is the default gateway when you create your APIs. If you are supporting the previous version 5 edition of APIC and you want to specify DataPower Gateway (v5-compatible), go to the Gateway tab | Gateway and portal settings in the navigation pane of your API. Scroll to the Catalog Properties section and you will find the Gateway selection option. Choose datapower-gateway.
By default, when you test an API with the Test tab, a range of test parameters are pre-configured, for example, a default Product is automatically generated, to which the API is added, and that Product is published to the sandbox catalog. You can configure testing preferences such as the target Product and target Catalog. Some of these configuration options are not available in LTE though.
You should now feel sufficiently prepared to embark on the journey of enriching your API Proxy with Policies and Variables. Policies and Variables are the building blocks for adding functionality to your Proxies. These are often used to add custom logic, transformation, routing, logging, and security capabilities to the Proxies. Variables and Policies are important to understand so that you can use them to enhance an API Proxy’s functionality. You will begin by learning about variables.
Using variables
Like any mature application development framework, APIC also supports various variable types to help manage/manipulate the data being passed in an API and control API’s Policies’ behavior. There are two types of variables supported by APIC: Context variables and API properties.
Context variables
These are the variables that are relevant during the context of an API call. Therefore, their scope is also limited to the context of a specific API call on the runtime gateway. There are several context variables available. You can refer to the complete list at https://www.ibm.com/docs/en/api-connect/10.0.1.x?topic=reference-api-connect-context-variables.
Context variables are categorized into the following categories:
Each category contains information about a particular aspect of an API call. Here are some of the most used categories:
- api: Provides API metadata, for example, API name, version, operation path, and provider organization information. One of the important elements of interest in this category is api.properties.propertyname. propertyname can be any custom property (catalog specific) defined for the API. API properties will be discussed in detail in the next section.
- client: Provides information about the client’s organization information and the client’s application that issued the request to the API.
- message: One of the most heavily used categories. This is the payload of the request or response message. Note that this is different from the request category (discussed next). Loosely, the message category represents a message as it moves in processing policy. You can read/write data to the message category. If you need to make any modifications to request and response payloads, then the message category is your playground.
- request: This represents the original HTTP request, its headers, URI, verb, parameters, and so on. This is read-only. And this is the fundamental difference between the message and the request category. HTTP request headers can be modified in the preflow policies.
- system: Provides system data and time information of the gateway.
Of course, you may not need to use all the different categories, but you should be aware of some of the more useful context variables. These are shown in Table 4.3.
Table 4.3 – Important context variables
You can read more about context categories and some associated variables of the message and request categories at https://www.ibm.com/docs/en/datapower-gateways/10.0.x?topic=object-context-api-gateway-services.
Now that you know some of the useful context variables, you should become familiar with how API properties are used.