The document discusses the impact of APIs on integration. It covers topics like SOA and microservices, REST design principles, security considerations, and evolving API management platforms. SOA principles are still valid and can be implemented through REST architectures. While REST aims to be simple, design decisions around areas like granularity and HATEOS are important. Security standards for REST APIs are emerging but not fully mature. API management has become a focus area for both integration vendors and new cloud-native companies.

1. Yann LE BLEVEC, SmartWave
June, 10th 2015
API Day, Lausanne
IMPACT OF APIs ON INTEGRATION
Nothing is lost, nothing is created, everything is transformed

2. June 2015 API Day, Lausanne 2
AGENDA
• SOA IS DEAD, LONG LIVE TO SOA!
– Trends, success stories, SOA & [W,R]OA, microservices
• REST IS SIMPLE, ISN’T IT?
– Design principles, resources, granularity, HATEOS, RMM
• SECURITY REVISITED
– Empowerment, adoption, standards
• EVOLVING NEEDS, EVOLVING PLATFORMS
– Editors, key buildings blocks, B2D

3. June 2015 API Day, Lausanne 3
SOA IS DEAD, LONG LIVE TO SOA!
Trends, success stories, SOA & [W,R]OA, microservices

4. June 2015 API Day, Lausanne 4
SOA MUST BE DEAD
• No longer a buzzword for editors and analysts
• Use of SOAP, WS-* standards is decreasing
• ESB are seen as too complex
• Governance sounds frightening
• Even SOA Software has changed its brand to Akama
BUT…

5. June 2015 API Day, Lausanne 5
EXPLOSION OF APIs

6. June 2015 API Day, Lausanne 6
PROVIDERS HEAVILY RELY ON SERVICES
WHO?
• Amazon, Twitter, Netflix…
"
WHY?
• Scale with load
• Remain agile
• Keep pace of innovation

7. June 2015 API Day, Lausanne 7
MICROSERVICE IS THE NEW HYPE
• Limitations of monolithic applications
– Code base grow substantially more complex
– Difficult to scale individual portions of the application
– Engineering team structure mirror the application architecture
• Implement autonomous building blocks
– Contain everything from the OS, platform, framework, runtime, and
dependencies, packaged as one unit of execution

8. June 2015 API Day, Lausanne 8
SOA DESIGN PRINCIPLES STILL VALID
• Standardized Contract
• Loose Coupling
• Abstraction
• Reusability
• Autonomy
• Statelessness
• Discoverability
• Composability

9. • REST architecture provides a medium by which service-
oriented architecture can be implemented
June 2015 API Day, Lausanne 9
REST TO THE RESCUE

10. June 2015 API Day, Lausanne 10
REST IS SIMPLE, ISN’T IT?
Design principles, resources, granularity, HATEOS, RMM

11. June 2015 API Day, Lausanne 11
REST DESIGN PRINCIPLES
CONSTRAINTS
• Client-Server
• Stateless
• Cache
• Interface/Uniform Contract
• Layered System
• Code-on-Demand
GOALS
• Performance
• Scalability
• Simplicity
• Modifiability
• Visibility
• Portability
• Reliability

12. June 2015 API Day, Lausanne 12
UNIFORM CONTRACT
resource identifier syntax
(e.g. URL)
methods
(e.g. HTTP)
media types
(e.g. IANA registry)

13. June 2015 API Day, Lausanne 13
DEALING WITH GRANULARITY
ENTITY
• Relate to noun
• May contain sub-resources
• Map CRUD to HTTP method
1. Single Customer resource with
large structure containing Address
2. Root Customer resource with
Address sub-resource
TASK
• Relate to verb
• Provide business context (intent)
• Define a state
• May implement composition logic
1. Single ChangeOfAddress resource
containing new address
• Design matters
– Chatty protocol, location of composition logic, information needed for updating

14. June 2015 API Day, Lausanne 14
IMPORTANCE OF HATEOAS
Hypermedia as the Engine of Application State

15. June 2015 API Day, Lausanne 15
RESTFUL MATURITY MODEL

16. June 2015 API Day, Lausanne 16
SECURITY REVISITED
Empowerment, adoption, standards

17. June 2015 API Day, Lausanne 17
SECURITY CONTEXT IS CHANGING
• New challenges
– Users manage authorizations and keep their password secure
– Developers register applications against APIs
– Lower constraint on API consumers
• New technologies
– REST replacing SOAP
– JSON replacing XML
• New standards
– Emerging standards with various maturity level
– Do not meet all historic requirements

18. June 2015 API Day, Lausanne 18
SECURITY FOR WEB SERVICES
• Securing Web Services is doable
– XML Encryption/Signature: provide crypto. foundation
– WS-Security: define security within SOAP messages
– SAML: transport assertions
– WS-Trust: retrieve token from central service (STS)
– WS-Policy: advertise expectations
• But rarely done
– Too complex to understand/maintain
– Impact service performance
– Suffer from interoperability issues

19. June 2015 API Day, Lausanne 19
SECURITY FOR RESTFUL APIs
• Adoption is the key
– Always rely on transport protocol (HTTPS) for integrity and
confidentiality
– May use HTTP header for authentication
– Commonly implement OAuth for authorization
– Often use OpenID Connect for authentication
– Rarely require cryptographic capabilities on consumer side

20. June 2015 API Day, Lausanne 20
OAUTH 2.0 WEB FLOW

21. June 2015 API Day, Lausanne 21
CURRENT ISSUES
• Various maturity of standards for JSON (JOSE)
– JSON Web Token (JWT)
– JSON Web Signature (JWS)
– JSON Web Encryption (JWE)
• Not “out-of-the-box” requirements
– Couple access tokens with message content
– Apply cryptographic operation to partially message content
– Support “end-to-end” requirements (integrity, confidentiality)

22. June 2015 API Day, Lausanne 22
EVOLVING NEEDS, EVOLVING
PLATFORMS
Editors, key buildings blocks, B2D

23. June 2015 API Day, Lausanne 23
DRIVERS FOR APIs
• Build a broad open web community with simple and free
REST APIs
• Support mobile app development with REST APIs
• Facilitate internal use of SOAP APIs and REST APIs for an
enterprise services strategy
• Act as an API service provider that charges for API access
• Build a B2B community around mission-critical APIs

24. June 2015 API Day, Lausanne 24
SOLUTIONS FOR API MANAGEMENT

25. June 2015 API Day, Lausanne 25
KEY CHARACTERISTICS
MARKET
• Topic covered by mega vendors
• Strong presence of historic integration actors
• New players appear mostly cloud based
COMPONENTS
• Runtime for exposing APIs with mediation capabilities
• Analytics for insights about APIs usage
• Monetization of published APIs
• Design time components for developer community (B2D)

26. June 2015 API Day, Lausanne
AXWAY API SOLUTIONS
26

27. June 2015 API Day, Lausanne
WSO2 API SOLUTIONS
27

28. June 2015 API Day, Lausanne 28
API MANAGEMENT VS MBAAS
Mobile Backend as a Service

29. June 2015 API Day, Lausanne 29
CONCLUSION

30. June 2015 API Day, Lausanne 30
KEY TAKEAWAYS
• Forget about the name not the principles
• REST can bring much but design matters
• Security is challenging out of main stream
• Platform may support your strategy

31. June 2014 WSO2CON - Glue SaaS using WSO2 31
YANN LE BLEVEC, PHD!
Head of Integration
yleblevec@smartwavesa.com
@yleblevec
SMARTWAVE SA!
Switzerland
http://www.smartwavesa.com
THANK YOU

32. June 2015 API Day, Lausanne 32
APPENDIX

33. June 2015 API Day, Lausanne 33
XML VS JSON

34. June 2015 API Day, Lausanne 34

35. June 2015 API Day, Lausanne 35

36. June 2015 API Day, Lausanne 36

37. June 2015 API Day, Lausanne 37

38. June 2015 API Day, Lausanne 38
SOA GOALS – 1/2
• Increased Intrinsic Interoperability
– Services within a given boundary are designed to be naturally compatible so
they can be effectively assembled and reconfigured in response to changing
business requirements
• Increased Federation
– Services establish a standardized contract layer that is federated, enabling it to
hide underlying disparity that allows services to be individually governed and
evolved
• Increased Vendor Diversification Options
– A service-oriented environment is based on a vendor-neutral architectural
model, allowing the organization to evolve the architecture in tandem with the
business without being limited to proprietary vendor platform characteristics
• Increased Business and Technology Alignment
– Some services are designed with a business-centric functional context,
allowing them to mirror and evolve with the business of the organization

39. June 2015 API Day, Lausanne 39
SOA GOALS – 2/2
• Increased ROI
– Most services are delivered and viewed as IT assets that are expected
to provide repeated value that surpasses the cost of delivery and
ownership
• Increased Organizational Agility
– New and changing business requirements can be fulfilled more rapidly
by establishing an environment in which solutions can be assembled
or augmented with reduced effort by leveraging the reusability and
native interoperability of existing services
• Reduced IT Burden
– The enterprise as a whole is streamlined as a result of the previously
described goals and benefits, allowing IT itself to better support the
organization by providing more value with less cost and less overall
burden.

40. June 2015 API Day, Lausanne 40
SOA DESIGN PRINCIPLES – 1/2
• Standardized Service Contract
– Services within the same service inventory are in compliance with the
same contract design standards
• Service Loose Coupling
– Service contracts impose low consumer coupling requirements and
are themselves decoupled from their surrounding environments
• Service Abstraction
– Services contracts only contain essential information and information
about services is limited to what is published in the service contracts
• Service Reusability
– Services contain and express agnostic logic and can be positioned as
reusable enterprise resources

41. June 2015 API Day, Lausanne 41
SOA DESIGN PRINCIPLES – 2/2
• Service Autonomy
– Services exercise a high level of control over their underlying
runtime execution environment
• Service Statelessness
– Service minimize resource consumption by deferring the
management of state information when necessary
• Service Discoverability
– Service are supplemented with communicative meta data by which
they can be effectively discovered and interpreted
• Service Composability
– Services are effective composition participants regardless of the
sire and complexity of the composition

42. June 2015 API Day, Lausanne 42
GARTNER Magic Quadrant for Application
Services Governance

43. June 2015 API Day, Lausanne
ORACLE API SOLUTIONS
43

44. June 2015 API Day, Lausanne 44
SUCCESSFUL PROVIDERS RELY ON SOC
TWITTER

45. June 2015 API Day, Lausanne 45
TWITTER

46. June 2015 API Day, Lausanne 46
FORRESTER EVALUATION