Overview
Reuse is a key SOA architectural principle that should always be of consideration when developing a solution. When creating an Oracle API Gateway (OAG) policy that is used to virtualize an OSB REST endpoint (for further details, see Oracle API Data Sheet), it can be done in a generic way allowing for a high level of reuse.
The key to creating a generic policy is defining the API Gateway path with the same value as the OSB endpoint URI. But before the OAG relative path can be created, the policy that virtualizes OSB REST endpoints will need to be implemented first.
REST Policy
As a refresher, an OAG filter is an executable rule that performs a specific type of processing on a message. An OAG policy is a network of message filters in which each filter is a modular unit that processes a message. For more details, see OAG concepts.
Within the OAG Policy Studio, create a policy (Policies->Add Policy), then add ‘Extract REST Request Attributes’ as the start filter. This will extract the Request query string (which is the string parameters from an HTTP POST or GET request) as well as the Request HTTP headers. Doing this provides the ability to reference these values later within the policy.
Next, add a ‘Connect to URL’ filter into the policy. This filter is the step in the policy where the invocation to the endpoint (OSB REST service in our case) is performed. Since we are building this policy to be used in a generic way, the URL of the Service Bus proxy will be generated from the input string of the request into the API Gateway. The http.request.path contains the path on which the HTTP request from the client is received by the API Gateway (which is also the same URI as the OSB proxy, i.e. /someName/ProxyService). The attribute http.raw.querystring contains the parameters (i.e. first=john&last=smith) from the request. Appending this within the URL will enable the request input parameters to be passed along to the OSB proxy.
The completed policy looks like this:
Listener Path
With the generic policy created, it can now be mapped to a relative path that the API Gateway will listen for traffic on. As mentioned above, the endpoints in both the OSB proxy and the OAG path resolver need to be the same to allow the OAG policy to be reused for any OSB REST endpoint.
Below is the OSB proxy endpoint URI proxy:
The same URI as above will be used when creating the listener path in OAG:
Summary
As the growth of APIs accelerate, it is important to maximize the reuse potential of your API Gateway. Creating generic policies as demonstrated here will enable agility, requiring minimal configuration when new APIs come online.