En esta charla se abordarán los diversos retos que se presentan cuando se requieren diseñar APIs REST usando la JVM. Los retos que se deben afrontar son diversos y cada uno de ellos tiene su contexto y complejidad. Contrato del API. ¿Cómo no romper el API? ¿Cómo proveer soporte para diversas versiones? ¿Cómo documentar? Modelo de programación del API. ¿Qué tipo de REST hacer? ¿Qué framework elegir? ¿Qué lineamientos de desarrollo seguir? ¿Debemos crear un cliente del API? ¿Debemos generar clientes del API para dispositivos móviles? ¿Debe ser mi API distribuida? ¿Necesito interactuar con sistemas externos? ¿Cómo debe mi API soportar caídas de sistemas externos? ¿Qué es eso de resiliencia? ¿Debe ser mi API residente por diseño? ¿Debo soportar altas cargas de tráfico en cortos períodos de tiempo? ¿Cómo diseño mi API para que sea escalable? ¿Cómo implemento alta disponibilidad? ¿Debo correr en la nube para escalar automáticamente? ¿Cómo hago escalamiento de mi API si no corro en la nube? ¿Cómo despliego mi API? ¿Debo resolver el aprovisionamiento de recursos que mi API necesita? ¿Qué es eso de Linux Containers? ¿Me sirve Docker para correr mi API? ¿Cómo ejecuto mi API en mi ambiente local?

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