1.
1
Tél : +33 (0)1 58 56 10 00
Fax : +33 (0)1 58 56 10 01
www.octo.com© OCTO 2015
50, avenue des Champs-Elysées
75008 Paris - FRANCE
Top 7 wrong common beliefs
about Enterprise API
implementation

2.
2
Mohamed KISSA
API
Consultant
mkissa@octo.com
@MedKissa
Antoine CHANTALOU
Head
of
WOA
&
API
achantalou@octo.com
@achantalou

3.
3
#1. API ?
I already have 800 SOAP services !

4.
4
SOAP
vs
REST

5.
5
Nick Gall [VP Gartner Group]
! “WS-* style Web Services are "Web" in name only…
! The W3C should extricate itself from further direct work on SOAP, WDSL, or
any other WS-* specifications”
David Orchard [Web Services standards – BEA]
! “Given the complexity of just SOAP and WSDL, how many developers will
really be able to move to the full stack?...
! The promise of WSDL 2.0 has not materialized and is unlikely to do so”
Paul Downey [Technical Architect at the Government Digital Service]
! “The SOAP "stack" is a mess, and currently only the simplest of services are
able to interoperate”
Steve Loughran [Apache Axis commiter]
! “The only place SOAP survives is in the enterprise because you can control
both ends of the conversation, you can use the same toolkit and eliminate
interop”
Steve Vinoski [Former VP & Chief Architect of IONA Technologies]
! “if I were an enterprise architect today…I’d be looking to solve everything I
possibly could with dynamic languages and REST
! I’d avoid ESBs and the typical enterprise middleware frameworks unless I had a
problem that really required them. I’d also try to totally avoid SOAP and WS-*”
SOAP vs REST

6.
6
SOAP vs REST
It’s about architecture
Style

7.
7
SOAP vs REST
RPC & SOAP
• Are operation/service oriented
• Tend to unify locale and remote
computation
• Are contract & server oriented
REST
• Is resource oriented
• Explicitly use WEB distributed
architecture
• Is developer oriented

8.
8
SOAP vs REST
Integrating your legacy SOA
implementations in your
API Strategy
…could end up into
URBANIZATION Strategy
• Monitoring
• Accounting
Focusing on the REST
approach inspired by Web
Giants
…may end up by building a
state of the Art API
• RESTful
• Developer portal
• TTFAC* & DX**
• X-device / X-channel
* “Time To First API Call” is the time a developer needs to consume the API in production after reading the documentation on the developer portal!
We target 5 minutes.
** “Developer experience”. The API is used by humans. We target a massive adoption. API needs to be crafted with love.
Which API Strategy ?

9.
9
SOAP vs REST

10.
10
#2. An API strategy
…is only about buying
a product

11.
11
Build vs Buy
Cheaper resources
Unique,
differentiating
Perceived
as a
competitive
advantage
Common to all
companies in the sector
Perceived as a
production asset
BPO*
Common to all companies
Perceived as a resource
Strategic assets and fast innovation
*Business Process Outsourcing
API PORTALS & SECURITY
API
! The API becomes the main entry point
to your CORE IT
! Critical & differentiating components
! A Key to a competitive advantage
! API Management are ineffective to
build good API
! API Management portal
! Resource publication & versioning
! Usage Statistics
! Quotas
! Developers’ portal
! Developers enrolment
! API documentation
! Security
! OAuth2 / OpenID connect

12.
12
#3. API Management
…it’s an ESB right?

13.
13
Anatomy of
API Management
solutions
API
Management
is not an ESB
Security
API_KEY
OAuth2 / OIDC
API Facade
(ESB)
API Management
portal
Users enrolment
Publication/ versioning
Usage statistics
Quotas
Developer portal
Self-enrolment
API Doc / Try-it interface

14.
14
ESB et API Management
API MANAGEMENT
• Entry point of the IS for
external/internal use
• May offers light
transformation/mapping
features
• Focused on API consumer:
enrollment, developer
portal, try-it console, etc.
ESB
• Supposed to be in the heart
of the IS
• Offer advanced
transformation/mappings
over several protocols
• Limited feature for
consumers

15.
15
#4. Opening my API to the WEB ?
The web is not secure !

16.
16
HTTPS
þ All requests are secured with TLS (RFC5246).
Authorization
þ API_KEY authorize clients on public resources
þ OAuth2 (RFC6749) authorize both clients and users on private resources
Authentication
þ OpenID connect authenticate users on private API resources
API securityMandatory
Optional

17.
17
« Everything
should be
made as
simple as
possible,
but not
simpler.»
A.Einstein
API security

18.
18
Beware of OAuth2
complexity
v OAuth2 out-of-the-box
implementation almost
never work without
specifics developments
v OAuth2 flows are
often partially
implemented
v Four flows must be
POCed
API security

19.
19
API security
What about other
protocols ?
• Don’t use other legacy protocols
• OAuth1, SAML2, etc.
• Don’t use encryption/signatures on
the applicative side
• Don’t implement customs security
solutions

20.
20
#5. API facade is the right pattern !

21.
21
+ Short time to market (good for a
MVP)
- Put dependency toward the API
Management/ESB editor
- May not handle the complexity of
your business logic
- A performance overhead should be
considered
- The API Management/ESB and your
existing service become highly
coupled
IS
Existing Services
API Management
Gateway or plugin
accounting, authorization,
statistics, etc.
Transformation/mapping
to REST
Scenario 1: API Facade through an API Management
Transformation

22.
22
+ Short time to market (good for a
MVP)
+ Will handle the complexity of
your business logic
- A performance overhead should be
considered
- The facade and your existing
services become highly coupledIS
Existing Services
API Facade
API Management Gateway or plugin
accounting, authorization,
statistics, etc.
Transformation/mapping
to REST
Scenario 2: Custom API Facade

23.
23
A great API on
bad services
is lipstick on a pig
API Facade pattern

24.
24
Scenario 3: Microservice pattern
+ No dependency toward an
editor
+ Will handle the complexity
of your business logic
+ No performance overhead
+ Fastest pattern to scale
your API once MVP is
validated
- Not time to market for your
API at stage one (MVP)
IS
API
API Management
Microservices
Gateway or plugin
accounting, authorization,
statistics, etc.
API API

25.
25
#6. API strategy?
It’s just
technical !

26.
26
API technical stakes
• Security, stateless, asyncronisme, non-transactional,
microservices, cloud hosting, ect.
API functional stakes
• API design
• Identify enterprise’ resources (X-channels, X-device)
• Building a REST API state diagram
• HATEOAS
API organizational stakes
• Conway’s Law : “Any organization that designs a system
[...] will inevitably produce a design whose structure is a
copy of the organization's communication structure”
• Organize your teams as you would like your IT system to
be !
API 360 impacts
API 360 impacts

27.
27
API 360 impacts
API is not about technical implementation, it’s not a short-time project, it's
about building a product!• “Did you already heard that Gmail development was finished and that it
was send under MRO (maintain, repair and operations) ?”
Consider a small autonomous and empowered agile team

28.
28
API 360 impacts
Product Owner [Business]
• Sync development with other
teams
• Responsible for API success
• Define Follow-up indicators
• Mesure, learn and build
Tech-lead / Devs [IT]
• Design & develop API
resources
• Write API documentation
• Measure and improve API
performance
• Write unit automated test
A
P
I
S
Q
U
A
D
Business analysts
[Business/IT]
• Co-design API resources
• Write automated
functional tests (TDR)
OPS [IT]
• Automated testing
• Automated deployment
• Scalability (elasticity)
and SLA
Community manager
[Marketing]
• Animate External Developers
community (API users)
• Social networking
• Administrate developer portal

29.
29
#7. I want to build an API for me & my partners,
but I’m NOT interested in OPEN API !

30.
30
v The main difference lies in the way you need to industrialize the enrolment
process and the quality that is required for your API
v You should target Open API from the beginning :
v So that you can fully industrialize the way developers consume your “services” on your
developer portal : https://developers.fakecompany.com!
v This is the only way to offer good enrolment, TTFAC & online support
Level 1 « Internal API»
API used by the company
Level 2 « Partners API »
API used by internal developers &
partners developers
Level 3 « Open API »
API used by internal developers, partners
developers & external developers

31.
31
Tél : +33 (0)1 58 56 10 00
Fax : +33 (0)1 58 56 10 01
www.octo.com© OCTO 2015
50, avenue des Champs-Elysées
75008 Paris - FRANCE
Thank you !
Mohamed KISSA
API
Consultant
@OCTO
Technology
mkissa@octo.com
@MedKissa
Antoine CHANTALOU
Head
of
WOA
&
API
@OCTO
Technology
achantalou@octo.com
@achantalou