##569 API Platform Cloud Service Introduction

Here is an introduction to our new API Platform Cloud Service functionality.

Firstly, what is Oracle's solution in this space?

API Platform Cloud Service is for teams who build APIs and want to focus on delivering great products.

  - It is the only solution that supports the complete API Lifecycle

  - It allows developers, architects and business to work together

  - It is superior to traditional API Management tools that take too much 

    effort to stitch together and maintain.

Thanks to my colleague, Robert W. for the succinct description.

So, now that you know you are getting your hands on the best solution out there, let's dive in.

API Platform CS Basic Demo

To demo basic functionality, I will be using the following service from Google finance

as my back-end business service.

http://finance.google.com/finance/info

The service provides stock quotes - e.g. ?client=ig&q=NASDAQ%3AORCL

will give me the Oracle stock price from the NASDAQ.

Let's start with some basics - API Platform Cloud Service has 3 main components -

1. The Management Console - here I can create APIs, apply policies to them.
From here I can also deploy APIs to Gateways - more about them later. From the management console, I can also publish APIS to my Developer Portal.

2. The Developer Portal - developers log in and see which APIs are available to them. APIs are used in the context of an Application - more about that later.

3. The Gateway(s) - this is the runtime component enforcing the policies.

Gateways can be deployed anywhere, both on cloud and on premise. The binaries are available for download from the API Manager portal. Once installed, the Gateways then register themselves with the Management Portal.

Here is a succinct architecture slide -

I will discuss the Apiary integration in a future post.

So now to the simple example -

1. Creating an API

I login to the management console and create the API, based on the Google stock quote.

Edit by clicking on the name.

You see the basic structure above - we have a Request and a Response pipeline, each of which can be augmented by policies.

API Request: The API Request is the location at which developers who consume your APIs will send their requests. This endpoint resides on the gateway on which the API is deployed. 

I set this as follows -

Service Request: The Service Request is the location of the backend service. If all policy conditions are met, this is the location to which the gateway passes the request. 

I set this as follows -

I only have straight thru processing implemented, but let's test this out anyway -

2. Deploy to the Gateway

Now I pick up the url and test in Postman -

Simple, isn't it?

Next, I  will add a policy and publish the api to the developer portal.

3. Add a Policy

I will add a key validation policy -

So, the request will be rejected if the header is missing or if the key is invalid - more to that later.

Now, I need to redeploy the API to the gateway. Remember, policies are enforced there, so the gateway needs the new definition of the API which now includes the policy.

4. Publish to the Developer portal

First thing I do is define the name.

Then I click Publish to Portal -

5. Register for API usage via the Developer Portal

I log in to the Developer Portal and see the API.

I click on it and then select Register -

I need to register an API in the context of an application. Think of a mobile app, leveraging my Stock Quote Service to provide stock trading functionality.

I click Create New Application -

Note the auto-generated Application Key above.

I click Register API and then I'm done.

Note: API Platform includes very finely grained permissions.
The user I'm logged in as is essentially a superuser. However, I could also
restrict my developers by giving them only the permissions to request usage of the API.
Then, the API owner, via the management console can grant them access.

Here is the owner's view of the Stock Quote Service usage now -

I will cover API Platform roles in a later post.I will cover API Platform roles in a later post.
Suffice to know, there is a comprehensive grants model at work.

Now, let's test again in Postman -

Make's sense - now let's add the key to the request.

Re-test - 

6. Monitor

Back in the Management Console - 

I can view the error stats -

I can view response times in the various layers -

and much, much more.


As we say in Ireland - Great Stuff!