39,59 €
Mehr erfahren.
- Herausgeber: Packt Publishing
- Kategorie: Wissenschaft und neue Technologien
- Sprache: Englisch
Work with the newest Oracle API Platform Cloud Service to interface with the increasingly complex array of services your clients want.
Key Features Understand the architecture and functionality of the new Oracle API Cloud Service Platform Understand typical use cases for the new platform and how it can work for you Design your own APIs, then deploy and customize your APIs Implement Oauth 2.0 policy and custom policies Migrate from Oracle 12c solutions to the new Oracle API platformBook Description
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.
What you will learn Get an overview of the Oracle API Cloud Service Platform See typical use cases of the Oracle API Cloud Service Platform Design your own APIs using Apiary Build and run microservices Set up API gateways with the new API platform from Oracle Customize developer portals Configuration management Implement Oauth 2.0 policies Implement custom policies Get a policy SDK overview Transition from Oracle API Management 12c to the new Oracle API platformWho this book is for
This book is for all Oracle developers who are working or plan to work with the Oracle API Platform Cloud Service.
Andrew Bell works at Capgemini, where he is a Senior Applications Consultant for the Oracle Practice. He has more than 30 years’ experience in the IT industry covering a wide range of software products and industry verticals. Sander Rensen has been involved his whole career in the integration space, with over 12 years of experience in the IT Industry. Sander started his career as a developer migrating large sets of data, but his organizational and leadership skills were soon noticed, which he applied successfully across a variety of data migration projects. Luis Weir is an Oracle Ace Director and a Thought Leader in PaaS technologies and SOA. With more than 15 years of experience implementing IT solutions across the globe, Luis has been exposed to a wide variety of business problems, many of which he has solved by adopting traditional SOA architectures, API management, and now Microservice Architectures. Phil Wilkins has spent over 25 years in the software industry with a breadth of experience in different businesses and environments from multinationals to software start-ups and customer organizations including a global optical and auditory healthcare provider.
Das E-Book können Sie in Legimi-Apps oder einer beliebigen App lesen, die das folgende Format unterstützen:
Seitenzahl: 441
Veröffentlichungsjahr: 2018
Ähnliche
Implementing Oracle API Platform Cloud Service
Copyright © 2018 Packt Publishing
All rights reserved. No part of this book may be reproduced, stored in a retrieval system, or transmitted in any form or by any means, without the prior written permission of the publisher, except in the case of brief quotations embedded in critical articles or reviews.
Every effort has been made in the preparation of this book to ensure the accuracy of the information presented. However, the information contained in this book is sold without warranty, either express or implied. Neither the authors, nor Packt Publishing or its dealers and distributors, will be held liable for any damages caused or alleged to have been caused directly or indirectly by this book.
Packt Publishing has endeavored to provide trademark information about all of the companies and products mentioned in this book by the appropriate use of capitals. However, Packt Publishing cannot guarantee the accuracy of this information.
Acquisition Editor: Dominic ShakeshaftContent Development Editor: Alex SorentinhoTechnical Editor:Gaurav GavasProject Coordinator:Suzanne CoutinhoProofreader:Tom JacobIndexer:Tejal Daruwale SoniGraphics:Tom ScariaProduction Coordinator:Nilesh Mohite
First published: May 2018
Production reference: 1310518
Published by Packt Publishing Ltd. Livery Place 35 Livery Street Birmingham B3 2PB, UK.
ISBN 978-1-78847-865-6
www.packtpub.com
Mapt is an online digital library that gives you full access to over 5,000 books and videos, as well as industry leading tools to help you plan your personal development and advance your career. For more information, please visit our website.
Why subscribe?
Spend less time learning and more time coding with practical eBooks and Videos from over 4,000 industry professionals
Improve your learning with Skill Plans built especially for you
Get a free eBook or video every month
Mapt is fully searchable
Copy and paste, print, and bookmark content
PacktPub.com
Did you know that Packt offers eBook versions of every book published, with PDF and ePub files available? You can upgrade to the eBook version at www.PacktPub.com and as a print book customer, you are entitled to a discount on the eBook copy. Get in touch with us at [email protected] for more details.
At www.PacktPub.com, you can also read a collection of free technical articles, sign up for a range of free newsletters, and receive exclusive discounts and offers on Packt books and eBooks.
Foreword
At this point in time, tens of thousands of companies are exploring solutions for how to better design, build, and manage applications with the aim of improving their customer experience and growing their bottom line. The application development domain is vast, yet so elegant and simple, so long as fundamental principles of architecture are understood and adhered to. APIs form an essential principle that if incorporated into application design and architecture will help produce applications that are simple to develop, manage, and evolve. These benefits free organizations to allocate more of their development capacity to improving their user experiences, adding capabilities, optimization of experiences, and innovation of new experiences.
APIs as a concept were discovered, meaning that they exist whether they are consciously accounted for at the time of design, or if they are inadvertently created as a by product of service development. Like doors to a building, APIs can be specific considerations or an afterthought. Any person who has used a building where doors are explicitly designed for the needs of the user's interaction with the building appreciates the elegance and flow of maneuvering into and within the building. Consider how buildings used for different purposes, such as hotels, airports, personal homes, and retail stores, have vastly different use cases for their doors ranging from the main entrance, delivery docks for trucks, gates for airplanes, to the storage of valuables just to name a few examples. Also, consider how doors also play a major role in security ranging from crime prevention, privacy, fire prevention, and more. If one can appreciate the importance of doors in our society, one will realize the importance of API design and API management in the application development domain. For users to have the feeling of elegance when using or managing an application, proper API design and management must be done.
Tooling for API Design and Management has already become very mature, offering many capabilities to help development teams meet their goals in whichever circumstance they find themselves. While there is a continuing evolution in the tooling, which will continue for the time to come, the time to leverage the tooling is today. Thousands of companies, with tens of thousands more on the way, across all industries have already developed API initiatives and have incorporated industry tooling and best practices to launch successful internal and public APIs. For companies that have yet to start an explicit initiative for API Design and Management, the time is now.
This book will provide a specific perspective, using scenarios based on real-life use cases, on how to interpret and be successful with domain-specific concepts such as API first design, microservices-based backend implementation, API testing, monitoring, and more. For companies already well underway, this book will provide complementary information, which can be used to succeed with any industry standard tooling, but will use the Oracle API Platform Cloud Service as an example. Welcome to the API community!
Vikas Anand
Vice President Product Management,
Oracle Corporation
Contributors
About the authors
Andrew Bell works at Capgemini where he is a Senior Applications Consultant for the Oracle Practice. He has more than 30 years' experience in the IT industry covering a wide range of software products and industry verticals. He worked with Oracle products and toolsets for more than 25 years including 12 years working with Oracle SOA suite and Oracle BPM. He first started working in the SOA space 14 years ago, and has successfully delivered many challenging and complex Oracle Middleware projects for large blue-chip clients. In recent years, he has become involved with numerous SaaS-to-SaaS integration projects as well as API development and microservice architectures.
Andrew is well respected for his depth of knowledge in the areas of SOA, API design, and BPM. He has strong team lead and communication skills and a deep all round technical knowledge, which covers both the Oracle stack and Java.
Sander Rensen has been involved in the integration space with over 12 years of experience in the IT industry. Sander started his career as a developer in migrating large sets of data, but his organizational and leadership skills were soon taken noticed, which he applied successfully across a variety of data migration projects. Sander soon turned his attention to focus on traditional SOA architecture to develop, design, test, and lead SOA implementations to a successful outcome for his clients. In Capgemini, Sander executes two roles. He is leading the Oracle UK PaaS Team and is a PaaS Architect with his current focus on API Management and adapting microservice architecture.
Outside his project responsibilities Sander has an eye for young talent, and as part of the Capgemini Apprentice and Graduate Program helps to find the right talent, and once hired, advise them in their careers and include them in some of the initiatives that he is running. Sander is also an alumni of one of the Capgemini pretentious Future Leaders Programs.
Sander is a passionate advocate of integration technologies and shares his knowledge and insights on social media, presented at the Oracle User Group Conference (UKOUG), and helps his local charity with a cost-effective website.
Outside his work, after his family, Sander is keen in sports that involves anything with a ball at present, mainly tennis and golf.
Luis Weir is an Oracle Ace Director and a Thought Leader in PaaS technologies and SOA. With more than 15 years of experience implementing IT solutions across the globe, Luis has been exposed to a wide variety of business problems many of which he has solved by adopting traditional SOA architectures, API management, and now Microservice Architectures. As CTO of Capgemini’s UK Oracle DU, his current focus is in setting up the strategic technology direction for the practice and also in assisting key client accounts define and implement strategic solutions using modern Oracle and open source technologies that can help realize business benefits.
Having always had a natural talent for software, computers, and engineering in general, Luis's career in software started from an early age. Even before starting university, Luis's entrepreneurial spirit led him to start several ventures, including one of the very first social media websites in his country of origin (Venezuela) as well as a small software development firm. Although none of these ventures turned into a multi-million corporation, the experience and knowledge gained during this period led him to develop the passion for distributed software computing that inevitable led to SOA.
Luis is the co-author of Oracle API Management 12c Implementation (2015, Packt Publishing), Oracle SOA Governance 11g Implementation (2013, Packt Publishing), as well as numerous articles and white papers. Luis is also a frequent speaker at industry events including Oracle OpenWorld, and most recently at Oracle Code London, Beijing, Sydney, and San Francisco. Luis holds an MS in Corporate Networks and Systems Integration from the Universitat Politecnica de Valencia (UPV) and a BS in Electronics Engineering from the Universidad Nueva Esparta.
Phil Wilkins has spent over 25 years in the software industry with a breadth of experience in different businesses and environments from multinationals to software startups, and customer organizations including a global optical and auditory healthcare provider to specialist consulting. He started out as a developer on real-time mission critical solutions, and has worked his way up through technical and development leadership roles primarily in Java-based environments. Phil now works for Capgemini in a multi-award winning team (which includes his co-authors) specializing in cloud integration and API technologies and more generally with Oracle technologies.
Beyond his day job, Phil has contributed his knowledge and experience by providing input and support to the development of technical books (particularly with Packt Publishing), including co-authoring Implementing Oracle Integration Cloud Service. In addition to this, he has also had a number of articles published in technical journals in his own right as well as being an active blogger. Phil has presented a broad range of industry events from Oracle Open World in San Francisco to Special Interest Groups and Meetups, including running an Oracle Developer Meetup in London. Phil is also a member of the Middleware & Integration Special Interest Group Committee among others. Phil's expertise and contributions to the Oracle community have been acknowledged by Oracle by accrediting him as an Oracle Ace.
When not immersed in work and technology, he spends his downtime pursuing his passion for music and spending time with his wife and two boys.
About the reviewers
Ricardo Ferreira is a Principal Solution Architect at Oracle. He is part of a special division of Oracle's Engineering called The A-Team, a highly respected team within Oracle that has the responsibility of - succeed where all else failed - therefore helping Product Management, Sales, Consulting, and Support in their most complex challenges.
He has more than 20 years of experience, and throughout his professional career, he has held several technical roles, which goes from Software Engineering, Sales Consultancy, and ultimately Solution Architecture. Before joining Oracle in 2011, he worked for other technology vendors such as Red Hat, Progress Software, and IONA Technologies. His background has been particularly focused on Distributed Systems, specifically in the areas of Integration, APIs, Messaging, and In-Memory Computing.
Nowadays; Ricardo spends part of his time helping the Oracle API Platform Cloud Service product to evolve, by building needed features (he is the author of the REST 2 SOAP policy), helping the community inside and outside Oracle to address technical issues, being one of the Black Belt instructors for advanced classes of the product.
Arturo Viveros is an outstanding Mexican IT Professional currently based in Oslo, Norway. He is a certified Cloud Integration Architect with over 12 years of experience in the design, development, and delivery of software for a variety of customers and industries. Arturo is also a Developer Champion, Oracle ACE, and a published technology writer both in English and in Spanish. He also strives constantly to be involved with and support developer communities/user groups that focus on technologies such as Oracle, Cloud, Java, DevOps, Software Architecture, open source, and Blockchain. In his spare time, Arturo enjoys family life, reading, hiking, travelling, playing guitar, and practicing sports such as tennis, football, and skiing.
Rolando, with a passion of systems and applications integration, has spent most of his professional career working with customers to solve a common long time problem: Applications Integration.
Since his years in college he started to work with Hewlett Packard (Mexico), where he joined back in 2001. Even though his tenure with HP was short, he realized that his professional career should be focused on Applications Integration. He started to implement integration solutions with JAVA, XML, web services, EAI.
He graduated with honors and was the best qualified student of his generation (1997-2001) . He studied in Mexico at Universidad Iberoamericana.
An important event happened while he was working with HP. It was the HP and Compaq fusion. When that happened, a lot of changes occurred at HP and Rolando moved to Oracle. That pretty much changed his professional career to these days.
At Oracle, he was always focused in the Integration technology that Oracle had at that time. There were not too many products unlike today, but it was something to start with.
Then the Collaxa acquisition by Oracle happened, and that was the first step in this journey that has turned Rolando into one of the most respected professionals in the Oracle SOA space for the Latin-American market.
Rolando started to work with Oracle BPEL PM and had the opportunity to join the Oracle Product Management Team. He was the first PM for LAD in those days, covering from Mexico to Brazil.
From 2005 to 2010, he was a Principal Product Manager for the Latin-American region being in charge the whole Fusion Middleware stack. Those years were the ones when Oracle acquired most of the components that are the foundation of the current Middleware offering: BEA, Thor, SUN, Oblix, Tangosol, and so on. Rolando had to be proficient in the whole stack, which was a great challenge because of the extension of every product. All these had kept Rolando very busy in the whole region, and gave him the opportunity to work in the most important customer of the region. From Mexico to Argentina, Rolando collaborated with the different Oracle’s subsidiaries to promote the usage of Fusion Middleware.
Then in 2010 he joined S&P Solutions. He joined as an associate. S&P Solutions is one of the most important Oracle partners in the Latin-American region. In S&P, Rolando has had the opportunity to implement most of the Oracle Fusion Middleware stack, with top companies in Mexico (telcos, financial institutions, retailers, manufacturing, and construction).
Currently, Rolando and his company have evolved into a modern development technology consulting firm. New wave development around Microservices, APIs, DevOps, Containers, Chatbots, Opensource technology are deployed on the cloud.
Rolando is both an Oracle ACE and Oracle Developer Champion, and is also one of the leaders of the ORAMEX Oracle Users Group in Mexico. He has a lot of articles and posts published at his blog (oracleradio.blogspot.com) as well as in the Oracle Tecnhology Network for the Spanish speaking community.
Rolando wrote, back in 2015, Oracle API Management 12c Implementation together with some other friends and colleagues. This has been one of his greatest achievements in his career.
Packt is searching for authors like you
If you're interested in becoming an author for Packt, please visit authors.packtpub.com and apply today. We have worked with thousands of developers and tech professionals, just like you, to help them share their insight with the global tech community. You can make a general application, apply for a specific hot topic that we are recruiting an author for, or submit your own idea.
Acknowledgments by All Authors
Firstly, we would like to thank our employer, Capgemini UK, the Oracle DU and Colin Daly for supporting us in writing and promoting this book.
We would also like to thank our clients, specially Niklas Olsson, for entrusting on us the implementation of the Oracle API Platform CS, an experience which was very valuable to make the use cases of this book as close to reality as possible.
Special thanks to the Oracle API Platform CS Product Team, Vikas Anand, Darko Vukovic, Jakub Nesetril, Robert Wunderlich, Kathryn Lustenberger, and all other members, for creating such an amazing product and supporting us not just in writing this book but also implementing it for our clients. In addition to the Product Team, Oracle A-Team (Ricardo Ferreira, Andy Knight, Deepak Arora, and others) have been incredibly helpful and sharing with us their insights and tips and tricks. Also, thanks to Jürgen Kress who has been very supportive and engaging; enabling us as a partner and providing access and early sight of the product.
Last but not least, we would like to thank the Packt Publishing team, particularly Dominic Shakeshaft who took the time to help us get this project up and running.
Table of Contents
Title Page
Copyright and Credits
Implementing Oracle API Platform Cloud Service
Packt Upsell
Why subscribe?
PacktPub.com
Foreword
Contributors
About the authors
About the reviewers
Packt is searching for authors like you
Acknowledgments by All Authors
Preface
What is an API?
3rd generation APIs
What this book covers
How we have approached this book
What you need for this book
Who is the book for?
Conventions
Reader feedback
Customer support
Downloading the example code
Download the color images
Errata
Piracy
Questions
Platform Overview
What is the Oracle API platform?
Evolution of Oracle's API offering
Platform architecture
Components description
Management portal
APIs page
The API implementation page
The implementation section
The deployment section
The publication section
The grants section
Registration section
The analytics section
Applications page
The settings section
Grants section
The gateways page
Settings section
Properties section
Nodes section
Deployments section
Grants section
The analytics section
The services page
The settings section
The grants section
Service accounts page
The settings section
The grants section
The roles page
Users and groups
Platform settings page
General settings section
Developer portal settings section
Development portal
The API page
The API documentation section
API subscription
My applications page
The overview section
Subscribed APIs section
The grants section
The analytics section
Management service REST APIs
API plans
Apiary
The Apiary account
Apiary views
Apiary personal view
Apiary editor
Inspector
Documentation
Testing with Apiary
Apiary settings
People
Apiary team view
APIs
Styles
People
Settings
Billing
Account settings
Summary
Use Case
Scenario
Use case opportunities
IT landscape
Financial processes
Recorded material and related assets
Contracts
Identities
Audit trail
Logical data view
API requirements in detail
Product
Product for partners
Product for composers and artists
Product availability
Structuring the design approach
Exploring OMESA
Single purpose versus multipurpose APIs
Semi-decoupled and fully decoupled
Bounded context
Next steps
Summary
Designing the API
Scenario
The API design-first process
Step 1 – defining the API type
Single-purpose APIs
Multi-purpose APIs
MRA's Media Catalogue API – public and multi-purpose
Step 2 – defining the API's domain semantics
Step 3 – creating the API definition with its main resources
Step 4 – trying the API mock
Step 5 – defining MSON data structures
Step 6 – pushing the API blueprint to GitHub
Step 7 – publishing the API mock in Oracle API platform CS
Step 8 – setting up Dredd for continuous testing of API endpoints against the API blueprint
Summary
Building and Running the Microservice
What is a microservice?
Understanding the technical requirements
Building the Microservice
Step 1 – install Node.js and MongoDB
Step 2 – create the skeleton of the Media Catalogue Microservice
Step 3 – define the structure of the Media Catalogue Microservice
Step 4 – configure the Media Catalogue Microservice
Step 5 – define the data entity
Step 6 – code the interaction with the database
Step 7 – define the controller function
Step 8 – route the incoming request to the new controller function
Step 9 – test the microservice
Step 10 – package and deploy the microservice
Step 11 – updating the API endpoint and re-test using Dredd
Summary
Platform Setup and Gateway Configuration
Platform architecture
The concept of logical and physical gateways
Avoiding network latency for global deployments
Deployment for the use case
How many nodes
How many logical gateways
How much storage?
Gateway design decisions in our use case
One cloud management or several?
Single management instance
Multiple management instances
MRA's approach number of cloud management instances
Firewall or no firewall
Load balancing
Web proxies
Content Delivery Networks (CDNs)
Prerequisites to allow the API platform to be built
Background to the account types
Building the cloud
Default roles and users
Creating users inside API platform
Configuring Oracle traffic director
Network-based access controls
Setting up Apiary
Configure developer portal look and feel
Gateway life cycle and deployment
Gateway configuration
Where to get the logical gateway ID
Configuration JSON properties
Gateway prerequisites
Retrieving the gateway deployment package
Actioning the gateway deployment
Unpacking
Install
Configure
Start
Create
Join
Making the gateway production ready
Linux security
Log analytics
Dealing with certificates
Gateway lockdown
Summary
Defining Policies for APIs
Background
Common security threats
Denial-of-service attacks (DoS)
Payload attacks
Role of the gateway
HTTP and HTTPS
Throttling
Implementing APIs for MRA
Understanding policies
General guidelines for designing policies
Request and response pipeline policies
Defining polices
Inbound policies
Outbound policies
Defining rate limiting policies
API rate limiting policies
Steps to create a rate limiting policy
Application rate limiting policies
Creating an application rate policy
Testing the policy
Lightweight authorization checks
Creating an API key policy
Testing the API key
Logging
Enabling logging
Interface filtering
Creating an interface filter
Testing the policy
Cross origin resource sharing (CORS)
Creating a CORS policy
Testing the CORS policy
Gateway-based routing
Creating a gateway-based routing policy
Resource-based routing
Groovy policies
Response policies
API policy iterations
Monitoring APIs
Summary
Testing APIs with API Fortress
What is API Fortress?
Test management
Monitoring
Continuous deployment
Tools
Test the MRA Media Catalogue API
Create Media Catalogue test case
The GetArtistById test case
Test using the Jenkins plugin
Summary
Implementing OAuth 2.0
OAuth 2.0 overview
Client credentials
Resource owner password
Implicit
Authorization code
MRA use case
Implementation steps
Step 1 – obtaining an Oracle identity cloud account
Step 2 – configuring an Oracle identity cloud resource server
Step 3 – configuring an Oracle identity cloud client application
Step 4 – adding users and groups to client application
Step 5 – configuring the API platform gateway
Step 6 – applying OAuth 2.0 policies to APIs
Summary
Implementing Custom Policies
What is Groovy?
Why provide Groovy for logging?
How Groovy custom policies work?
APIs to access call data
How to reject an API call in a Groovy policy?
Recognizing Groovy errors
Groovy policy illustration
Addressing a problem with a simple Groovy policy
Building our API
Run the test
Implementing a Groovy policy for an API response
A closer look at Groovy language limitations
Custom Java policies
Composition of a custom Java policy
Creating a custom policy for MRA
Getting geolocation information
Simplifying the development process
Using an IDE
Build properties
Build process
Presentation definition
Supporting JavaScript
Localization of the UI
UI Backend for validating configuration
Backend implementation
API runtime
Metadata
Additional libraries
Deployment
Current constraints
Custom policies – which policy type to use?
Summary
Moving from API Management 12c to APIP CS
Oracle API management suite 12c
Oracle API manager 12c overview
Oracle API gateway 11g
Oracle API Platform Cloud Service
Mapping of personas and roles
Architectural differences
Strategy for transitioning APIs from OAPIM 12c to APIP CS
API re-implementation design
Service implementation
API definition and API-first design
API creation/policy implementation
API testing
API switch-over strategy
Defining API policies
Adding API documentation
Deploying endpoints
Testing the API
Publication of the API
Analytics
Summary
Another book You May Enjoy
Leave a review - let other readers know what you think
Preface
The ball game has changed for the IT industry. Organizations that today don't offer access to their products and services seamlessly through multiple channels, are not just considered outdated but are seriously seeing a decline in their market share. They are being disrupted.
This inflection point, arguably kick-started by the huge popularity of smartphones inevitably making mobile apps the benchmark for user experience, ended up introducing considerable pressure for businesses to modernize their IT landscape and therefore, keep up with the competition (digital giants and startups) and new demands of users in general (customers and employees):
Source: https://commons.wikimedia.org/wiki/File:Steve_Jobs_presents_iPhone.jpg
For digital giants such as Google, Apple, and Facebook, or even for a startup, this doesn't represent a real challenge. As many have said already, such organizations were born digital and therefore they are not directly exposed to such disruption, and if they were, they are ready to quickly respond to the challenge (that is, Snapchat vs Facebook, Waze vs Google Maps). For traditional organizations, on the other hand, which is the vast majority worldwide, this represents a huge challenge as they can't simply wipe their existing IT landscape and start from scratch.
Such organizations must carefully devise plans and strategies to modernize their business. They must make available considerable investments to digitally transform their operations and adapt to modern business models capable of engaging customers through digital channels in a more intimate and dynamic way.
But as organizations embark on the journey of digital transformation, it soon becomes evident that without reliable access to core information assets, delivering relevant and modern solutions that put the customer at the center is a real challenge.
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):
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.
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:
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.
3rd generation APIs
These few vendors understood that Microservices Architecture wasn't fundamentally different from SOA in terms of its principles. However, in terms of realization, the technologies used to implement microservices truly delivered to the promise of flexibility, scalability, and agility. Therefore, in order to deliver a modern 3rd generation API platform, they had to build a solution from the ground up with modern requirements in mind.
These vendors acknowledged that a 3rd generation API platform had to comply with at least the following requirements:
Implement APIs anywhere (in any vendor's cloud or on-premises) without introducing an operations nightmare and huge costs
Empower communities of developers by letting them discover and subscribe to APIs via a self-service developer portal
Deliver seamless tooling for end-to-end API development life cycle and API-first so developers get the tools they need to design, create, and test their APIs
Give information owners full visibility and control over their information by letting them decide how and by whom their assets are accessed
Deliver strong security to protect information assets against all major threats (that is, OWASP top 10)
Is lightweight, appliance-less/ESB-less, and suitable for Microservice Architectures
Is elastic (that is, can scale easily)
Is centrally managed regardless of the number of gateways, APIs, and their location
Makes meaningful use of statistics so operations data can be used to gain business insight and not just to monitor and troubleshoot
Is subscription-based, with no CPU-based licensing
This brings us neatly to the Oracle API Platform Cloud Service (Oracle APIP CS) and the goal of this book.
The Oracle APIP CS is a 3rd generation API platform built from the ground up to satisfy digital requirements and therefore is capable of meeting modern API demands.
In this book, we will explore the capabilities of the product and take a hypothetical use case (which is underpinned with real-world considerations that the authors have had to address) to demonstrate how the platform can be applied.
We will also show how to set up the product, follow an API-first approach to implement a microservice, manage it with the Oracle APIP CS and subsequently streamline the entire development life cycle with even automated testing.
The book also has a chapter in explaining how customers that have adopted the previous (2nd gen) Oracle API management solution can migrate to this new platform.
What this book covers
This book will take the reader through the following chapters:
Chapter 1, Platform Overview, provides a full and comprehensive overview of the platform, introducing key concepts and the capabilities from the perspective of the management console.
Chapter 2, Use Case, describes a hypothetical use case in which we can then illustrate the different aspects of the API Platform Cloud Service. While the case maybe hypothetical, the underpinning needs come from real-world scenarios the authors have seen.
Chapter 3, Designing the API, goes through the process of designing APIs following an API-design first approach taking a use case. This includes using features such as API definition using the API blueprint, API mocking to test the API behavior, and Dredd to unit-test an API implementation.
Chapter 4, Building and Running the Microservice, show how the API definition produced can be realized using microservice technologies as APIs are natural partners. To demonstrate the microservice, we'll deploy the service on Amazon using Docker and into Oracle's Container Cloud.
Chapter 5, Platform Setup and Gateway Configuration, goes into the detail of instantiating APIP, configuring the cloud platform and then installing and configuring an API gateway including all pre-requisites. We first need to install and configure an API gateway to be able to manage the API for our microservice. This chapter deals with this topic.
Chapter 6, Defining Policies for APIs, will take you through the process of looking at the policies available to us, and defining the policies to be used with our APIs and then deploy them now that we have a gateway ready, an API definition set, and its implementation done.
Chapter 7, Testing APIs with API Fortress, talks about API Fortress. With an API configured and deployed it needs to be tested. Whilst there are a number of tools available for this task API Fortress has a level of integration with the APIP CS, which makes the process even easier.
Chapter 8, Implementing OAuth 2.0, looks at how to set up OAuth 2.0 with the APIP CS and Oracle Identity Cloud, now that OAuth is becoming the defacto norm for authentication and authorization for user-based credentials for web services, particularly REST ones. In this chapter, we look at how to setup OAuth2 with the APIP CS and Oracle Identity Cloud.
Chapter 9, Implementing Custom Policies, will walk through the process of building custom API policies using Groovy scripting or the policy Java SDK. APIP CS provides several approaches to develop our own API policies and these will be covered in this chapter.
Chapter 10, Moving from API Management 12c to APIP CS, talks about transitioning to APIP CS. APIP CS is not the 1st Oracle API product. API Management 12c represents Oracle's 2nd generation of API Platform, and for those not starting with a clean sheet will need to understand the options for migrating from the older product.
How we have approached this book
The approach we have adopted with this book is worth explaining. If you read the section on the target audience, you'll note we're not aiming only at the developer community but at a wider potential user audience of API Platform Cloud Service. To help us do this, we have set ourselves some parameters that will help you understand why things have been done a particular way.
Use tools that the entire target audience can use and understand. So nice integrated developer tools are not used for most of the book. There are a couple of areas where they are relevant, though.
Do not force the reader to buy lots of extra products to allow the majority of the examples to be exercised. This does mean that rather than real-end systems, we use tools to allow us to pretend they exist. For example, the use of Apiary to mock up an API.
Use a real-world based use case to help illustrate the use of APIs.
Rather than explaining every step in each example, we have reduced the amount of explanation provided as certain activities need to be repeated, such as setting up certain API policies.
Conveying the ideas and concepts will always take priority over being puritan with best practice.
The Oracle APIP CS is fairly new and therefore is a maturing product. Everything in this book will hold largely true for a few years, even if the occasional screen label changes or stylesheets get updated the reader should understand what they are being shown, as well as how.
What you need for this book
Beyond the use of Oracle APIP CS, we have taken the approach of utilizing additional services and tools that are free wherever possible. We will explain in more detail the different tools and services, but let's start by just introducing what is needed:
Oracle Cloud Account—a trial Oracle APIP CS account will be sufficient for most things (as long as you have tried everything in the book within the trial period obviously)
Free accounts with Apiary (
https://apiary.io/
)
The CURL command-line tool to allow us to make simple calls to some API (
https://curl.haxx.se/
)
API Fortress for API testing (
http://apifortress.com/
)
Node.js as the core technology to build a microservice (
https://nodejs.org/en/
)
The Atom editor for editing a Node.js-based microservice (
https://atom.io/
)
Docker community edition for running the microservice in a container (
https://www.docker.com/community-edition
)
Who is the book for?
This book is mainly intended for architects and developers in general that wish to:
Understand the architecture and use cases for Oracle APIP CS
Implement API management enterprise-wide to govern the entire API life cycle
Implement API-first in the context of microservices architectures
Understand how to use Oracle APIP CS to manage microservice endpoints
Implement a developer portal to manage communities of developers
Conventions
The book has two key textual conventions. Identifying specific parts of the user interface are indicated by bold text like this, for example, click on the OK button. Where we are directing you to enter specific values into fields or looking for values that are driven by our inputs, then this kind of text is used. For example, complete the description with this is a description I have added.
Reader feedback
Feedback from our readers is always welcome. Let us know what you think about this book—what you liked or may have disliked. Reader feedback is important for us to develop titles that you really get the most out of.
To send us general feedback, simply send an e-mail to [email protected], and mention the book title via the subject of your message.
If there is a topic that you have expertise in and you are interested in either writing or contributing to a book, see our author guide on www.packtpub.com/authors.
Customer support
Now that you are the proud owner of a Packt book, we have a number of things to help you to get the most from your purchase.
Downloading the example code
The entire code used in all chapters of the book can be downloaded from the book's GitHub account at, http://apiplatform.cloud.
To get the files for this book from your Packt account at, http://www.packtpub.com. If you purchased this book elsewhere, you can visit http://www.packtpub.com/support and register to have the files e-mailed directly to you.
You can download the code files by following these steps:
Log in or register to our website using your e-mail address and password.
Hover the mouse pointer on the
SUPPORT
tab at the top.
Click on
Code Downloads & Errata
.
Enter the name of the book in the
Search
box.
Select the book for which you're looking to download the code files.
Choose from the drop-down menu where you purchased this book from.
Click on
Code Download
.
You can also download the code files by clicking on the Code Files button on the book's web page at the Packt Publishing website. This page can be accessed by entering the book's name in the Search box. Please note that you need to be logged in to your Packt account.
Once the file is downloaded, please make sure that you unzip or extract the folder using the latest version of:
WinRAR / 7-Zip for Windows
Zipeg / iZip / UnRarX for Mac
7-Zip / PeaZip for Linux
The code bundle for the book is also hosted on GitHub at, https://github.com/PacktPublishing/ImplementingOracleAPIPlatformCloudService.
We also have other code bundles from our rich catalog of books and videos available at, https://github.com/PacktPublishing/. Check them out!
Download the color images
We also provide a PDF file that has color images of the screenshots/diagrams used in this book. You can download it here: https://www.packtpub.com/sites/default/files/downloads/ImplementingOracleAPIPlatformCloudService_ColorImages.pdf.
Errata
Although we have taken every care to ensure the accuracy of our content, mistakes do happen. If you find a mistake in one of our books—maybe a mistake in the text or the code—we would be grateful if you would report this to us. By doing so, you can save other readers from frustration and help us improve subsequent versions of this book. If you find any errata, please report them by visiting http://www.packtpub.com/submit-errata, selecting your book, clicking on the Errata Submission Form link, and entering the details of your errata. Once your errata are verified, your submission will be accepted and the errata will be uploaded on our website, or added to any list of existing errata, under the Errata section of that title.
To view the previously submitted errata, go to https://www.packtpub.com/books/content/support and enter the name of the book in the search field. The required information will appear under the Errata section.
Piracy
Piracy of copyright material on the Internet is an ongoing problem across all media. At Packt, we take the protection of our copyright and licenses very seriously. If you come across any illegal copies of our works, in any form, on the Internet, please provide us with the location address or website name immediately so that we can pursue a remedy.
Please contact us at [email protected] with a link to the suspected pirated material.
We appreciate your help in protecting our authors, and our ability to bring you valuable content.
Questions
You can contact us at [email protected] if you are having a problem with any aspect of the book, and we will do our best to address it.
Platform Overview
The focus of this chapter is to provide a comprehensive yet detailed overview of the Oracle API Platform Cloud Service (APIP CS) architecture. The chapter starts off by providing a high-level view and explanation of the architectural components that build up the platform, continues by describing the different personas and roles that can interact with the platform, and finalizes by providing a sample implementation architecture.
In this chapter, you will find:
A walk-through platform evolution into 3
rd
generation
An overview of the Oracle API Platform
A look at the platform architecture
An introduction to Apiary
The management service APIs
Introduction to API plans
What is the Oracle API platform?
The Oracle API Platform Cloud Service is a 3rd generation API management platform (refer to the Preface for further context) built almost entirely from the ground up to satisfy modern integration requirements such as real-time access to information via REST APIs.
As its name suggests, the platform is a cloud-based Platform as a Service (PaaS), meaning that it can be purchased in a subscription-based model, metered or non-metered.
The platform supports the full life cycle of API management, from API design (using Apiary, which is described later in the chapter) to continuous integration, implementation, promotion, operations, and decommissioning/retirement.
The platform is fully hybrid meaning that it can be deployed in cloud computing but also on-premises. It's lightweight and equally well suited for Microservices Architecture, in other words, 3rd generation.
But what exactly is a 3rd generation API Platform in the context of Oracle product offering?
This concept is better understood by understanding the chronological evolution of Oracle's API offering throughout time.
In the following section it is described how Oracle's offering evolved from an Enterprise Service Bus centric architecture, to then becoming a SOA/SCA feature-rich (monolithic) platform, and then evolving into an architecture that is distributed, lighter weight, and therefore, suitable for hybrid and microservices architectures.
Evolution of Oracle's API offering
As described in the Preface of this book, APIs are not really new. What is new is how we refer to them in the context of the web architectures and the standards/technologies/protocols used to deliver them. For this reason, when looking back through time, one must also look at traditional integration platforms such as Enterprise Service Bus (ESB).
For example, Oracle's first ESB offering was part of the very first release of Oracle SOA Suite (10g) launched mid/late 2006. This ESB centric architecture, offered support for SOAP/WSDL-based APIs that at the time we referred to as web services. It also offered support for emerging standards such as Business Process Execution Language (BPEL) with BPEL Process Manager, WS-* standards such as WS-Security with Web Services Manager (WSM), business rules with the Rules Engine (also known as Rules Author) and real-time business dashboards with Business Activity Monitoring (BAM).
This ESB and open-standards centric architecture delivered the initial capabilities for XML-based APIs. This is why it is referred to in the diagram as Generation Zero. In other words, the starting point:
