SGCE 2015 REST APIs
Download as PDF, PPTX12 likes2,675 views
This document provides an overview of building REST APIs for distributed systems. It discusses motivation for APIs and the importance of an API contract. The document then covers tools for defining the API contract like RAML and code generation. It presents microservices architecture and implementation options using Spring Boot, Spring Cloud, and Netflix OSS frameworks. The talk concludes with a demo of a microservices application deployed with Docker.
More Related Content
Similar to SGCE 2015 REST APIs(20)
SGCE 2015 REST APIs
- 1. Enlighten your software RESTAPI design & dev Domingo Suárez Torres @domix http://github.com/domix http://domingosuarez.com Una propuesta de: “Como construir APIs REST para sistemas distribuidos con alta escalabilidad y resilencia" 1/jul/2015
- 2. Agenda • Preamble • Disclaimer •Context • Motivation • API • Contract • Programming model (architecture style)
- 3.
- 4. Disclaimer • This talkand 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.
- 5. Context • I’m notcovering Hypermedia REST APIs • I’m a JVM guy, so you will see lots of JVM references. Sorry.
- 6. Motivation • Functional requirementsis THE challenge. • API Documentation is always a PITA, keep 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.
- 7. SOAP No longer anacronym. Since 1.2
- 8. SOAP • Characteristics • Extensibility(security, routing) • Neutrality (transport protocol) • Independence (programming model)
- 9. SOAP architecture • Severallayers of specifications for: • Message format • Message Exchange Patterns • Underlying transport protocol bindings • Message processing models • Protocol extensibility
- 10. SOAP • Web ServicesDescription Language (WSDL) • Universal Description Discovery and Integration (UDDI)
- 11. SOAP • Complex specificationfor vendors • Developers take time to grok • Sometimes very long time • Misunderstanding of the guidelines.
- 12. I like SOAPintentions
- 13. I dislike SOAPcomplexity
- 14.
- 15. API Contract • Alwaysis 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.
- 16. API contract approaches •Contract last • Code driven contract • Contract first • Upfront design
- 17. Contract last • Sadlyis 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.
- 18. Contract first • Upfrontdesign API • Consumer perspective design • Reusability • Versioning • Performance
- 19. The contract ascorner stone for REST APIs
- 20. How to buildthe contract?
- 21.
- 25.
- 26. RAML, my favorite •YAML dialect + JSON schema #ftw (types) • Readable for humans. • Can be procesable by machines. • Design clear, correct, precise & consistent APIs. • No vendor lock-in.
- 31.
- 36. raml + raml-mockup Wecan deliver an API in days or hours
- 37. RAML & codegeneration • Server side • JAX-RS • Client • Square Retrofit • Documentation • HTML
- 38. raml2code • OpenSource projectfrom 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.
- 41. Nice, now Iknow how to create a contract. What’s next?
- 42.
- 43.
- 44. Services • 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.
- 45. Wait, a buzzword iscoming…
- 46. MicroServices architecture • ServiceContracts • RAML • Exposing new & existing services • Enterprise Integration Patterns (integration, routing, transformation) • Discovery of services • Service Registry
- 47. MicroServices architecture • Coordinationacross 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.
- 48.
- 50.
- 51. Spring Boot isawesome
- 52. –Spring Boot referencedocumentation “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.”
- 53. Spring Boot • EmbeddedServlet container • Tomcat • Jetty • Undertow • Executable jar file. Key feature for microservices! • Monitoring capabilities thanks to actuator • HealthChecks • Metrics (Dropwizard aka Coda Hale Metrics) • Jolokia
- 54. Spring Boot &JAX-RS • Jersey 2.x support out of the box • Just use the Jersey Starter • spring-boot-starter-jersey • raml2code generates JAX-RS artifacts, remember?
- 55. Spring Cloud • Distributed/versionedconfiguration • Service registration and discovery • Routing • Service-to-service calls • Load balancing • Circuit Breakers • Global locks • Leadership election and cluster state • Distributed messaging
- 56. Netflix OSS • Netflixis 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…
- 57.
- 58. Spring Boot &Spring Cloud for impatient developers
- 60.
- 61. Each circle isa Docker container read/write Hystrix send metrics Turbine listen events Turbine generates a http stream
- 62. Acknowledgments • To allthe platform team at Grupo Expansión • Alvaro Cabrera (@pateketrueke) • Anallely Olivares (@tsunllly) • Angel Pimentel (@blzb) • Eduardo Diaz (@iamedu) • Tomás Salazar (@atomsfat)
- 63.