Se ha denunciado esta presentación.
Utilizamos tu perfil de LinkedIn y tus datos de actividad para personalizar los anuncios y mostrarte publicidad más relevante. Puedes cambiar tus preferencias de publicidad en cualquier momento.
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 Pari...
2	

Mohamed KISSA
API	
  Consultant	
  
	
  
	
  	
  	
  	
  	
  	
  	
  	
  	
  	
  	
  mkissa@octo.com	
  
	
  	
  	
  	...
3	

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

SOAP
vs
REST
5	

Nick Gall [VP Gartner Group]
! “WS-* style Web Services are "Web" in name only…
! The W3C should extricate itself from...
6	

SOAP vs REST
It’s about architecture
Style
7	

SOAP vs REST
RPC & SOAP
• Are operation/service oriented
• Tend to unify locale and remote
computation
• Are contract ...
8	

SOAP vs REST
Integrating your legacy SOA
implementations in your
API Strategy
…could end up into
URBANIZATION Strategy...
9	

SOAP vs REST
10	

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

Build vs Buy
Cheaper resources
Unique,
differentiating
Perceived
as a
competitive
advantage
Common to all
companies i...
12	

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

Anatomy of
API Management
solutions
API
Management
is not an ESB
Security
API_KEY
OAuth2 / OIDC
API Facade
(ESB)
API ...
14	

ESB et API Management
API MANAGEMENT
•  Entry point of the IS for
external/internal use
•  May offers light
transform...
15	

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

HTTPS
þ  All requests are secured with TLS (RFC5246).
Authorization
þ  API_KEY authorize clients on public resource...
17	

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

Beware of OAuth2
complexity
v  OAuth2 out-of-the-box
implementation almost
never work without
specifics developments...
19	

API security
What about other
protocols ?
•  Don’t use other legacy protocols
•  OAuth1, SAML2, etc.
•  Don’t use enc...
20	

#5. API facade is the right pattern !
21	

+ Short time to market (good for a
MVP)
- Put dependency toward the API
Management/ESB editor
- May not handle the co...
22	

+ Short time to market (good for a
MVP)
+ Will handle the complexity of
your business logic
- A performance overhead ...
23	

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

Scenario 3: Microservice pattern
+ No dependency toward an
editor
+ Will handle the complexity
of your business logic...
25	

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

API technical stakes
•  Security, stateless, asyncronisme, non-transactional,
microservices, cloud hosting, ect.
API ...
27	

API 360 impacts
API is not about technical implementation, it’s not a short-time project, it's
about building a produ...
28	

API 360 impacts
Product Owner [Business]
•  Sync development with other
teams
•  Responsible for API success
•  Defin...
29	

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

v  The main difference lies in the way you need to industrialize the enrolment
process and the quality that is requi...
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 Par...
Próxima SlideShare
Cargando en…5
×

Top 7 wrong common beliefs about Enterprise API implementation

2.751 visualizaciones

Publicado el

OCTO Technology - API Days 2015

Publicado en: Tecnología
  • Thanks for sharing. When opposing API Management and ESB I use to say that to expose services ESB is required if, and only if custom mapping (composition, orchestration, transformation) is required. (please note that ESB can propose much more than just exposing services like adapters with other technologies).
       Responder 
    ¿Estás seguro?    No
    Tu mensaje aparecerá aquí

Top 7 wrong common beliefs about Enterprise API implementation

  1. 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. 2 Mohamed KISSA API  Consultant                          mkissa@octo.com                                @MedKissa   Antoine CHANTALOU Head  of  WOA  &  API                          achantalou@octo.com                                @achantalou  
  3. 3. 3 #1. API ? I already have 800 SOAP services !
  4. 4. 4 SOAP vs REST
  5. 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. 6 SOAP vs REST It’s about architecture Style
  7. 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. 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. 9 SOAP vs REST
  10. 10. 10 #2. An API strategy …is only about buying a product
  11. 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. 12 #3. API Management …it’s an ESB right?
  13. 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. 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. 15 #4. Opening my API to the WEB ? The web is not secure !
  16. 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. 17 « Everything should be made as simple as possible, but not simpler.» A.Einstein API security
  18. 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. 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. 20 #5. API facade is the right pattern !
  21. 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. 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. 23 A great API on bad services is lipstick on a pig API Facade pattern
  24. 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. 25 #6. API strategy? It’s just technical !
  26. 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. 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. 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. 29 #7. I want to build an API for me & my partners, but I’m NOT interested in OPEN API !
  30. 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. 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  

×