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
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 ?
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
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
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
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
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
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