Book Image

Implementing Oracle API Platform Cloud Service

By : Andrew Bell, Sander Rensen, Luis Weir, Phil Wilkins
Book Image

Implementing Oracle API Platform Cloud Service

By: Andrew Bell, Sander Rensen, Luis Weir, Phil Wilkins

Overview of this book

Implementing Oracle API Platform Cloud Service moves from theory to practice using the newest Oracle API management platform. This critical new platform for Oracle developers allows you to interface the complex array of services your clients expect in the modern world. First, you'll learn about Oracle’s new platform and get an overview of it, then you'll see a use case showing the functionality and use of this new platform for Oracle customers. Next, you’ll see the power of Apiary and begin designing your own APIs. From there, you’ll build and run microservices and set up the Oracle API gateways. Moving on, you’ll discover how to customize the developer portal and publish your own APIs. You’ll spend time looking at configuration management on the new platform, and implementing the Oauth 2.0 policy, as well as custom policies. The latest finance modules from Oracle will be examined, with some of the third party alternatives in sight as well. This broad-scoped book completes your journey with a clear examination of how to transition APIs from Oracle API Management 12c to the new Oracle API Platform, so that you can step into the future confidently.
Table of Contents (12 chapters)

What is an API?

Application Programming Interfaces (APIs) and the technologies and platforms that enable them, can bridge this gap. APIs can act as doors to previously locked information assets and key business functionality. APIs are already enabling millions of user experiences through a wide variety of devices such as smartphones, tablets, smart watches, bots to name just a few.

However, APIs are not new. APIs have been around for almost as long as there has been software development. In the early days of IT, APIs weren't anything like what we typically think of them today, but they have always embodied the same basic goals, namely a contract (explicit or implicit) that describes the data to be exchanged and an action. Today when we talk about APIs, we mostly refer to a specific type, REST APIs (also known as web APIs):

API evolution

In the days of COBOL (Common Business-Oriented Language) for example, the interface was often described through files containing structure definitions. As programming moved on to languages such as C, we saw interfaces become more explicit through things like header files.

As interface definitions developed within programming languages, the problem also needed to be addressed in distributed solutions. This resulted in the rise of frameworks like CORBA (Common Object Request Broker Architecture) where we saw contracts being defined with IDL (Interface Definition Language) combined with communications standards such as GIOB (General Inter-Orb Protocol) so information could be inter-exchanged among programs in distributed networks.

This type of rudimentary APIs had a problem, though. They either had aspects of the interface not clearly defined to understand the definition you had to interpret the actual code, or they were very restrictive in terms of the communications protocol, for example, RMI (Remote Method Invocation) for Java and IIOP (Internet Iner-ORB Protocol) for CORBA.

With the arrival of the Internet HTTP (Hypermedia Transfer Protocol), the protocol that truly enabled the World Wide Web, it was not long before new and more open protocols emerged. The use of HTTP, combined with the XML (Extensible Markup Language), gave birth to one of the most popular standards in modern distributed computing, SOAP (Simple Object Access Protocol). Along with WSDL (Web Service Description Language) as an interface definition language, both would be used in combination as the foundation to define web services.

It at this point that SOA (Service Oriented Architecture) was conceived. A vendor-neutral and open architectural style based on the notion that services, as core building blocks, could be composed in order to create more flexible solutions.

Note that at this point API as a term wasn't really used. Services was the main term used.

And the Enterprise Service Bus (ESB) was born. Introduced as the main mechanism to realize SOA, ESBs represented the evolution of traditional EAI (Enterprise Architecture Integration) tools. However, instead of using proprietary protocols, they used open web services standards. This made ESBs extremely popular to the point that most organizations worldwide still use ESBs to satisfy many of their integration needs.

ESBs delivered many good benefits, and for many years they satisfied common integration requirements. But as mentioned at the start, an inflection point would take the entire IT industry by surprise.

With the increased popularity of mobile apps and the wide availability of cloud computing (at this point becoming popular among large enterprises), REST (Representational State Transfer) is introduced as a much simpler and more efficient way to implement services. Only that they were not referred to as services but web APIs. Although not enforced by the REST specification itself, most REST implementers favor JSON (JavaScript Object Notation) over XML the format to send data in REST.

This new way to provide access proved to be much more lightweight and simpler to adopt than its SOAP/WSDL predecessor and quickly rocketed in popularity.

ESB/SOA vendors, while trying to keep up with new demands, quickly adapted their 1st generation SOA stacks and XML appliances to also support REST/JSON capabilities, giving the vendors at least some time to digest what was going on in the industry. These are known as 2nd generation API platforms; these are just adaptations of ESBs and XML appliances to support REST APIs:

API platform evolution – from ESBs to micro-gateways

Some vendors, however, truly acknowledging that there had been a fundamental change in the industry, understood that just putting lipstick on a pig wouldn't do. They understood that information had become federated, that access via APIs had become the new standard; but most importantly a new way to construct services, a new kid in the block, had arrived to stay: Microservices Architecture.