The document discusses common misconceptions about enterprise API implementation, highlighting key differences between SOAP and REST, and the importance of a comprehensive API strategy. It emphasizes that API management should focus on consumer needs rather than just technical integration and suggests strategies for building effective APIs. Additionally, it underscores the significance of organizational structure and collaboration in API development and promotes the idea of open APIs for better external engagement.

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