RubiX ID - API management - Pim Gaemers
-
Upload
rubix-bv -
Category
Technology
-
view
194 -
download
1
Transcript of RubiX ID - API management - Pim Gaemers
API ManagementSchiphol Case
06-04-2016
Introduction
Pim Gaemers
Integration Specialist from Rubix
Hired by Schiphol for:
Integration architecture
API Management (technical side)
Mechiel Aalbers
Technical Application Coordinator
API Platform
CISS (Central Information System Schiphol)
Public-Flight API
Agenda
API’s
Why API’s
When creating an API
When designing an API
API Management
recommendations
Why API Management
API Management at Schiphol
Infrastructure & components
Organization
Challenges & Lessons learned
summary
Q&A
Why API’s
- A clear overall corporate strategy for your API is an essential starting
point
- Make the business model clear from the beginning
Some high level examples:
To enable mobile as an additional channel
To grow ecosystems: customer (B2C) or partner ecosystems (B2B)
To develop massive reach, for transaction or content distribution
To power new business models
To drive internal innovation
When creating a new API
API’s are intrinsically worthless but receive their value from the
business assets and functionality they unlock.
Think of the value of the effect of the API.
APIs can be among a company's greatest assets
Customers invest heavily: buying, writing, learning
Cost to stop using an API can be prohibitive
Successful public APIs capture customers
Can also be among company's greatest liabilities
Bad APIs result in unending stream of support calls
When designing an API
Ask yourself these questions beforehand
What business assets do I want to make available?
How do I want to make these assets available?
What kind of app can be built using this API?
What kind of incentive do developers have for using my API?
How do apps using my API bring value to my business?
Does the API bring direct value to my business via a pay-per-use
policy or via an indirect way.
API Management recommendations
Public APIs are forever - one chance to get it right
1. Focus relentlessly on the value of the API
2. Make the business model clear from the beginning
3. Design and implement with the user in mind
4. Place API operations at the top of the list
5. Obsess about developer experience
6. Go beyond marketing 101
7. Remember API retirement and change management
Source: The API owners manual. 3Scale
Why API Management
Uniform way to expose and distribute you API’s to the
community.
Both from a technical (endpoint) perspective
And from a developer experience perspective
Uniform way for authentication and authorization
(gateway to your data)
Enable throttling & subscription/payment
Enable monitoring & metrics
API management at Schiphol
Schiphol’s long term vision: To become the worlds
greatest digital airport. (we want to the best, start
innovation, take initiative, enhance the customer
journey at schiphol)
Why API Management
Enabling external development communities to
spearhead innovation
Unlocking business assets to businesspartners and
the general public (Flight API is the first)
Infrastructure and components
API Gateway
Developer portal
API Management portal
API’s
ESB
(Certain) Back-end
provided API’s
API Gateway
Used as an access point for your API calls
Essentially a reverse proxy
Used for:
Authentication
Authorization
Metrics
Throttling
Forwarding requests to API’s
API Management portal
Setup API’s for the API Gateway
Account management
Application plans (used for throttling)
Configuring the API Gateway
Developer portal
Access point for developers
for using the API
(live) Documentation
Use cases
Registering and account
management
Treat the developer portal
as a digital channel for your
organization. Developers
are people too
1. Focus relentlessly on the value of the API2. Make the business model clear from the beginning3. Design and implement with the user in mind5. Obsess about developer experience
Field testing the API5. Obsess about developer experience
6. Go beyond marketing 101
Challenges & Lessons learned
Everything must be an API
Push and notification API’s
To cache or not to cache (and more important
where)
What about infrastructure?
Organization mindset (pro actively thinking about
API’s as assets rather then reacting to customer
requests)
A governing data board
Lessons learned (everything must be an
API)
Every business opportunity and
request comes in: “We need an
API for this” (don’t hype it)
Other and better solutions may
exist
Lesson: Get involved in the design
process early on. Get the right
people on board in an API
design/support team
Lesson: come with clear cut best
practices and guidelines to help
the teams (don’t allow different
styles of making api’s)
Lessons learned (Push API)
That Rest API is wonderful, but we need to
have push notifications…”
Push API’s are challenging from technical
perspective and still cutting edge.
Manage connections
Manage subscriptions
Queries
No standardized technology
Oldskool resync?
Lesson: Manage expectations and design
early on. Make sure the API onboarding
processes is in place.
Lessons learned (caching)
To Cache or not to cache
Where to cache (http caching in the API gateway, application
specific cache in the application layer)
http caching is limited in functionality and requires plain http (think
about cache hits)
Lessons: Think about caching
possibilities and strategy from the
beginning. Using it as a patch to
quickly improve performance might not
be a good idea
Lessons learned (infrastructure)
Infrastructure is complex
Cloud vs on-premise
Where to host the gateway
Where to host the API (and data)
Where to place caching
What form of security is required for infra and for the API’s
Lesson: Take time to design a good infrastructure with the right
people (networking, infrastructure, security, API team). Also take
legal issues into consideration when storing data outside the
network
Lessons learned (Organization mindset)
Organization mindset, organization
is used to react to customer
propositions
Now pro actively thinking about
the API value.
Thinking about business models
(pay per hit, monthly
subscription, free)
Lesson: Create business
awareness around API’s. What
makes a good API.
Lesson: Get key business decision
makers in the API team from the
start.
Governing data board
Clear mandate what data can be exposed to the outside world.
Frequent consults with business and legal slowed the process
Overall roadmap when, what API’s should become available
Lesson:
Get a clear roadmap for API’s with mandate to expose the
assets in the API.
Scalable to be infrastructure
In order to be more resilient, fault tolerant and scalable a new infrastructure
architecture leveraging the cloud has been created.
Summary
The API platform has become an essential foundation for
Schiphol to leverage their digital strategy
Experience with the 3Scale API platform has been
positive overall
“API mindset” is slowly but surely becoming more
prevalent at the Schiphol culture
Overall API management and platform experience at
Schiphol has been good!
How it all started
An API powered demo!
Q&A