Oracle API Platform – Page 2

Teaching How to Design and Secure an API with Oracle API Platform

This blog is the second part of an end-to-end exercise that starts explaining the steps to clone a GitHub repository that contains an agnostic Medical Records application, built by us in NodeJS and which exposes REST API endpoints via a Swagger API-descriptor running locally on Swagger UI (all included as part of the repository). The previous part of this 2-blogs series also explains the steps required to run the MedRec NodeJS application on Docker containers either locally or in the Oracle Public Cloud. For more information about this first part, go here.

Moving to this second part, we are going to cover the following steps:

Create an Apiary account used to Design APIs (API First approach) and create a new API Project using the existing MedRec Swagger API-definition.
We are going to spend a little bit of time playing with Apiary to feel comfortable in areas such as:
1. Validating API definitions
2. Testing API endpoints
3. Switching across out-of-the-box Mock Servers and real Production MedRec service end-points.
Login to Oracle API Platform and configure an API, this includes:
1. Enforcing Security and other policies.
2. Deploy API and securing access level to on-premise and Cloud-based API Gateways.
3. Publishing APIs into the API Developers Portal.
4. Linking API to Apiary Swagger API-definition living document.
Login to API Developers Portal (API Catalog)
1. Register a New Application
2. Understanding the role of API Keys
3. Reviewing MedRec API Documentation
4. Registering to consume MedRec APIs
5. Testing APIs.
Understand API Analytics, consumption, metrics and monitoring dashboards.

Continue reading “Teaching How to Design and Secure an API with Oracle API Platform”

Experimenting with Fn project

The first AppDev Made Easy (previously known as DX Workshop) for this tour started in Perth. We are continually trialing a few different things as such as we incorporated Fn project https://fnproject.io.

The whole demonstration of Functions was to articulate that there are different ways to execute and understanding the problem to solve as well as the values that the organisation holds (including both business and IT departments including developers) which will determine the technology.

For the demo we start from the very beginning.

Continue reading “Experimenting with Fn project”

Teaching best practices to Design, Build, Secure and Monitor APIs

In this blog, I want to share my experience after having created many APIs using different approaches and technologies. I am going to encapsulate a simple process that will help you construct APIs, starting from scratch with an idea or requirement and move it all along to a happy consumption.

The best part of APIs is that they are microservices enablers, which implies that they are not technology prescriptive, so in this blog you will see that your APIs can be implemented using any technology or programming language.

I decided to use “Jokes” as the vehicle to explain the APIs construction best practices, mainly because jokes are a simple concept that anyone can relate to, but also because I want you to feel compelled to consume these APIs and by doing so, get a laugh or two.

My original idea with jokes is to:

Get a random joke.
Translate the joke to any language.
Share the original or the translated joke with a friend via SMS.

This is the high-level view of how our end solution will look like:

Continue reading “Teaching best practices to Design, Build, Secure and Monitor APIs”

Apiary designed APIs tested using Dredd

APIs are becoming the window to the digital assets of the modern business. Well documented, well governed and easy to use APIs are key to their successful uptake, longevity and associated business success. Yes, I did say well documented. In this instance I am talking about the documentation required to describe the APIs capabilities in a manner that is meaningful for your ultimate audience, the “API Consumers”, however it will also provide the template for the API Developer to develop their code from. In the modern business climate, we probably don’t want to produce War and Peace, we simply want to take a minimum viable approach to our API documentation. But where would I find a capability that will simplify our task as API Designers, capture the design documentation for our APIs, allow us to do some initialise testing to validate the usefulness of our design before any code is cut, and also have the documentation ready for consumption by team members and interested parties using a standards based approach. Where indeed ! Look no further than Apiary.io. Continue reading “Apiary designed APIs tested using Dredd”

Teaching How to simplify building NodeJS APIs with Loopback Framework

In this blog, I am going to show you how to get started with the Loopback framework to easily auto-build REST APIs in NodeJS and persistence layer in a variety of options, including relational and non-relational databases e.g. In-memory DB, MongoDB, MySQL, Cassandra, Oracle, etc.

In terms of API design and development, Loopback allows you to work “top-down” or “bottom-up”. I am going to cover both approaches in this blog.

First, we are going to create an API model definition in place, as we are building the REST APIs, this exercise will give us a Swagger-based API definition. Alternatively, we are going to start from an existing Swagger definition and use it to implement NodeJS REST APIs pointing to a persistence layer of choice (in-memory DB, MongoDB, MySQL, DB2, Oracle, etc.). I personally prefer the “API First/Top Down” approach, as it gives me the option to properly design and test my APIs first and then, simply move to implementation phase, but this ultimately depends on situations, preferences and requirements.

Continue reading “Teaching How to simplify building NodeJS APIs with Loopback Framework”

Teaching how to DevOps automate the provisioning of external APIs using Oracle API Platform and Developer Cloud Service

Modern Integrations require touching lots of different APIs coming from multiple “systems”. These “systems” can be big enterprise backend applications, such as: E-Business Suite, SAP, JDE, Siebel, etc. As well as modern SaaS Applications, such as: Service Cloud, ERP Cloud, Salesforce, Netsuite, Workday, etc. These “systems” can also be other smaller or custom applications running either on premise or in the cloud exposing either SOAP or REST services.

Rarely any of these “systems” can provide solid abilities to remotely expose APIs in a way that are tailored for a specific business case. Commonly, to achieve this, we need a separate integration layer that orchestrates APIs from multiple “systems” and easily obtain the desired business outcome, in a way that they are also reusable APIs to be utilise in other business scenarios. Furthermore, in order to properly apply security measures and effectively protect these APIs and safely expose them to external consumers (potentially in the public Internet), normally we need to use an API Gateway (see this blog to learn how).

Also, in previous blogs, John Graves showed us how to automate the creation and deployment of existing “internal Integration APIs” and expose them as secured external APIs using Oracle API Platform. (See ICS to API Platform and Oracle Service Bus to API Platform).

If we take the same automation concept, we can then apply it in a DevOps scenario, where we want to achieve the following:

Continue reading “Teaching how to DevOps automate the provisioning of external APIs using Oracle API Platform and Developer Cloud Service”

Teaching how to secure access to on-premise Applications with Oracle API Platform

In this blog, I am going to show you how to use the API gateway from the Oracle API Platform, to secure the access to backend Applications. These internal applications might already be exposing REST APIs, but given these are internal APIs, being exposed by backend applications themselves, we simply don’t want to directly expose them into the public Internet.

There are many reasons for this, for example, the backend application might not have the right ability to fully secure its APIs for external use, nor to have the right ability to control access authorisation, throttle requests, apply different policies, validate custom headers, apply API-KEYs, run analytics, etc. Normally only an API Gateway can do all these different things.

I can think of the 3 most common ways to securely get access to backend applications behind a corporate firewall.

Using secured APIs exposed externally
Connecting through a secured VPN tunnel
Using a messaging pattern, like with the Oracle Integration Cloud Service Agents deployed locally and then gathering access externally via Integration Cloud Service console or APIs