The document discusses the construction of REST APIs for distributed systems with a focus on scalability and resilience, sharing personal experiences and opinions. It emphasizes the importance of having a clear API contract, different approaches to API design, and the use of tools like RAML for development. Additionally, it touches on microservices architecture, Spring Boot, and the integration of Netflix OSS components to enhance service management and deployment.

1. A P I R E S T W I T H J AVA
A N O P I N I O N A T E D A P P R O A C H
Lima, Perú. Diciembre 2015

2. – B E C A U S E A N A
'Como construir APIs REST para sistemas
distribuidos con alta escalabilidad y resilencia '

3. D I S C L A I M E R
• This talk and its contents are based in my own
experience.
• I’m not trying to say all the following IS the way to do
the right thing. Just my opinion. :)
• All I want is to share my experience with the
community.
• This talk is huge. Hope I can finish on time.

4. M O T I VAT I O N
• Functional requirements is THE challenge.
• API Documentation is always a PITA, keep in sync with
the maintenance, new features, fixes, etc.
• Build any API (REST, SOAP, RPC) is hard.
• Development tools choice (programming language,
libraries, frameworks, runtime, etc).
• Non functional requirements, quality attributes.

5. A P I C O N T R A C T

6. A P I C O N T R A C T
• Always is over there. Implicit/Explicit
• You should have one.
• You should know it.
• No matter if you build it or you consume the API.
• You should give it so much love.
• Learn to love it.

7. A P I C O N T R A C T A P P R O A C H E S
• Contract last
• Code driven contract
• Contract first
• Upfront design

8. C O N T R A C T L A S T
• Sadly is the commonest.
• Server-side developers dictate the contract.
• Most of the time with only one perspective.
• Implementator perspective VS consumer perpective
• Flaky. If missing test cases. Fragile.
• The documentation is done at the end.
• Bottleneck.

9. C O N T R A C T F I R S T
• Upfront design API
• Consumer perspective design
• Reusability
• Versioning
• Performance

10. The contract as corner stone for REST APIs

11. H O W T O B U I L D T H E
C O N T R A C T ?

12. T O O L S

16. S O M A N Y O T H E R S : )

17. R A M L , M Y FAV O R I T E
• YAML dialect + JSON schema #ftw (types)
• Readable for humans.
• Can be procesable by machines.
• Design clear, correct, precise & consistent APIs.
• No vendor lock-in.

22. J S O N - S C H E M A S A M P L E

25. D E S I G N & B U I L D

30. R A M L + R A M L - M O C K U P
We can deliver an API in days or hours

31. R A M L & C O D E G E N E R AT I O N
• Server side
• JAX-RS
• Client
• Square Retrofit
• Documentation
• HTML

32. R A M L 2 C O D E
• OpenSource project from Grupo Expansión
• Generates Plain Old Java/Groovy Objects
• Generates JAX-RS interfases
• Generates an API client with Retrofit
• Can run in Android also in any JVM application.

35. N I C E , N O W I K N O W H O W T O C R E AT E
A C O N T R A C T. W H AT ’ S N E X T ?

36. P R O G R A M M I N G M O D E L
Architecture

37. S O A + E D A

38. S E R V I C E S
• Build, deploy, and monitor any kind of services in
agile, efficient way with open standards.
• Deployment on-premise, in the cloud, mix of both.
• Deploy services independently from each other.
• Decoupled & scale linearly across commodity
hardware.

39. WA I T, A B U Z Z W O R D
I S C O M I N G …

40. M I C R O S E R V I C E S A R C H I T E C T U R E
• Service Contracts
• RAML
• Exposing new & existing services
• Enterprise Integration Patterns (integration, routing,
transformation)
• Discovery of services
• Service Registry

41. M I C R O S E R V I C E S A R C H I T E C T U R E
• Coordination across services
• Event Bus, (smart service, dump pipe)
• Managing complex deployments and their scalability
• Build Tool, CI, DevOps (Chef, Puppet), Linux
Containers, Cloud, monitoring
• Visibility and correlation across services
• Event correlation, ElasticSearch, Logstash, Kibana.

42. S O U N D S N I C E , B U T…

44. I M P L E M E N TAT I O N
D E TA I L S

45. S P R I N G B O O T I S
A W E S O M E

46. – S P R I N G B O O T R E F E R E N C E D O C U M E N TAT I O N
“Spring Boot makes it easy to create stand-alone,
production-grade Spring based Applications that
you can “just run”. We take an opinionated view of
the Spring platform and third-party libraries so you
can get started with minimum fuss. Most Spring
Boot applications need very little Spring
configuration.”

47. S P R I N G B O O T
• Embedded Servlet container
• Tomcat
• Jetty
• Undertow
• Executable jar file. Key feature for microservices!
• Monitoring capabilities thanks to actuator
• HealthChecks
• Metrics (Dropwizard aka Coda Hale Metrics)
• Jolokia

48. S P R I N G B O O T & J A X - R S
• Jersey 2.x support out of the box
• Just use the Jersey Starter
• spring-boot-starter-jersey
• raml2code generates JAX-RS artifacts, remember?

49. S P R I N G C L O U D
• Distributed/versioned configuration
• Service registration and discovery
• Routing
• Service-to-service calls
• Load balancing
• Circuit Breakers
• Global locks
• Leadership election and cluster state
• Distributed messaging

50. N E T F L I X O S S
• Netflix is released tons of good stuff.
• Reactive Extensions for Java
• Hystrix (Circuit breaker)
• Eureka (Service registry)
• Archaius (Configuration management)
• Zuul (Dynamic routing, monitoring, resilience, security)
• And many more…

51. S P R I N G B O O T L O V E S
N E T F L I X O S S

52. S P R I N G B O O T & S P R I N G C L O U D
F O R I M PAT I E N T D E V E L O P E R S

54. A C K N O W L E D G M E N T S
• To all the platform team at Grupo Expansión
• Alvaro Cabrera (@pateketrueke)
• Anallely Olivares (@tsunllly)
• Angel Pimentel (@blzb)
• Eduardo Diaz (@iamedu)
• Tomás Salazar (@atomsfat)
• Domingo Suarez Torres (@domix)

55. C O N TA C T O
• http://twitter.com/domix
• domingo.suarez@gmail.com
• http://domingosuarez.com
• http://github.com/domix