#640 APIP CS 18.2.5

Just a simple example to show how streamlined our API Platform is. Kudos to our engineers.

So let's start out with an API Definition in Apiary -

This service manages service request tickets, you can well imagine that Service Cloud is behind this.

Anyway - I will take the mock server URL for this service and use it in my API definition in APIP CS.

The url is as follows -

So here we go - on to API Platform Management console -

Creating an API -

Note: I will create a Plan later. Essentially Plans are a way of bundling APIs for developer use.

Step 1 - I add the link to Apiary -

With the Specification taken care of, let's move on to the implementation -

Let's start by specifying the following -

Service Request is the Apiary URL -
API Request is the vanity URL I specify.

Service Request -

As you can see above, I could enter the actual Apiary URL - this is fine for one offs.
However, I could also click Select Service, which essentially just virtualises the Apiary URL for me -
this is a better approach, if re-use is expected. Naturally, I would have to define the Service first - let's do that!

Defining a Service

that was easy!

Back 2 Creating an API -

Now back to the API definition - where we can leverage the Service -

You may be asking - what is a Service Account?
Essentially a way of reusing credentials -

I do not need this for my Apiary service.

Now I set API Request - the proxy, so to speak.
This is what developers will see.

So they will interface with the AATicketService.

We have just implemented pass thru processing -

No Policies have been applied, as yet - plenty of time for that later.

Gateways and Deployment

I can now deploy the API to a Gateway - pre-requisite is naturally enough, a Gateway.

The gateway is a piece of software you can download from the console and deploy anywhere -
on premise, in the Oracle Cloud or in any other cloud. Registration with the management console is part of the gateway installation process.

You can check the nodes, to see if they are still up and reachable.
Note the polling interval and Last Polled timestamp.

Note also the Download Gateway Installer button.

Now back to my API Definition -

I click Deploy API and select the target gateway -

Waiting - for gateway to poll. Gateway polls at a frequency you define.
It pick up the new API definition and deploys it.

Done!

I can now pick up the URL and test it via Postman -

Here is the response -

Great stuff! So how can I expose this API to my developers?
Let's start by creating a Plan -

Create a Plan

at Settings level we can set the Plan Rate Limit -

from the Oradocs -

Rate limits are a way of giving applications more requests at higher cost levels.
Rate limits apply across all entitlements. For example, you have a plan with
entitlements to three different APIs, and then set a rate limit of 1000 requests per
minute. This means that requests to all three APIs combined cannot exceed 1000 per
minute.Rate limits are a way of giving applications more requests at higher cost levels.
Rate limits apply across all entitlements. For example, you have a plan with
entitlements to three different APIs, and then set a rate limit of 1000 requests per
minute. This means that requests to all three APIs combined cannot exceed 1000 per
minute.

You can select one or multiple gateways through which the plan will allow the APIs to be invoked.

I just accept the defaults.

Entitlements are essentially the APIs I add to the plan -

Note the states - Inactive and Unpublished

I activate the API within the context of this Plan -

The API is currently not yet published to the Developer Portal, again, I can do that now,
within the context of the Plan. But I will also need to publish the API directly.

I can now deploy the plan to the Developer portal -

Last step - publish the API

Consuming the API via Developer Portal

APIs are consumed within the context of an application. More about that below.

Our developer could go straight to the API list and subscribe to the Plan from there -

or via the Plans...

Apis/Plans are consumed via an Application. For example, our developer wants to consume our API from her mobile app.

She clicks on My Applications and creates one -

Note the appKey -

She clicks on the 2nd icon - Subscriptions

or she can go directly to the Plan and click Subscribe -

Last step - the developer needs the URL for accessing API - this is available here -
check out the Endpoint URLs