Successfully reported this slideshow.
We use your LinkedIn profile and activity data to personalize ads and to show you more relevant ads. You can change your ad preferences anytime.

REST and Microservices


Published on

An introduction to the microservice architectural style, including how to be RESTful using HTTP.

Published in: Software
  • You have to choose carefully. ⇒ ⇐ offers a professional writing service. I highly recommend them. The papers are delivered on time and customers are their first priority. This is their website: ⇒ ⇐
    Are you sure you want to  Yes  No
    Your message goes here
  • You can ask here for a help. They helped me a lot an i`m highly satisfied with quality of work done. I can promise you 100% un-plagiarized text and good experts there. Use with pleasure! ⇒ ⇐
    Are you sure you want to  Yes  No
    Your message goes here
  • Hello! I can recommend a site that has helped me. It's called ⇒ ⇐ They helped me for writing my quality research paper.
    Are you sure you want to  Yes  No
    Your message goes here
  • Don't forget another good way of simplifying your writing is using external resources (such as ). This will definitely make your life more easier
    Are you sure you want to  Yes  No
    Your message goes here

REST and Microservices

  1. 1. Shaun Abram Shaun Abram An introduction to Microservices and REST November 15th, 2014
  2. 2. Shaun Abram 2 Microservices What is a microservice?  A small, focused piece of software  Independently developed, deployed, upgraded  Commonly exposes it functionality via HTTP/REST
  3. 3. Shaun Abram 3 Microservices - definition The microservice architectural style is an approach to developing a single application as a suite of small services, each running in its own process and communicating with lightweight mechanisms, often an HTTP resource API. - “Microservices” by Martin Fowler and James Lewis
  4. 4. Shaun Abram 4 Microservices - Not a new concept! Unix Philosophy (1984) A set of philosophical approaches to developing small yet capable software For example:  Do one thing well  Play well with other programs  Use standard interfaces Contrasts with Monoliths…
  5. 5. Shaun Abram 5 The Monolithic Architecture An application built & deployed as a single artifact  Easy to setup - single project in an IDE  Easy to deploy - a single war file  Scaled horizontally (load balanced servers) Keep things simple! YAGNI?
  6. 6. Shaun Abram 6 Problems with Monoliths  Slow to build, too big to easily understand  Forced team dependencies  How do you split up teams?  Obstacle to frequent deployments  Long-term commitment to a technology stack
  7. 7. Shaun Abram 7 Conway’s Law Organizations which design systems are constrained to produce designs which are copies of the communication structures of these organizations - M. Conway (1968) In order for two software modules to interface correctly, the developers of each must communicate. The resulting interface will reflect the structure of the teams. "If you have four groups working on a compiler, you'll get a 4-pass compiler”
  8. 8. Shaun Abram 8 Why use Microservices?  Focus on specific business functionality, not tech  Think cross-functional, or ‘full stack’ So, what are the advantages of using microservices?
  9. 9. Shaun Abram 9 Advantages of microservices  Small?  Single, focused purpose  Independently deployable  Independently scalable, resilient
  10. 10. Shaun Abram 10 Advantages of microservices  Small?  Single, focused purpose  Independently deployable  Independently scalable, resilient  Independent technology stack
  11. 11. Shaun Abram 11 Disadvantages of microservices  Distributed architectures are hard!  Refactoring across service boundaries  Interface changes are hard  Use flexible, forgiving, broad interfaces  Be as tolerant as possible  “Be conservative in what you do, liberal in what you accept”— Jon Postel  Operational complexity e.g. monitoring and problem detection
  12. 12. Shaun Abram 12 Microservices vs SOA Both architectural design patterns; Collections of services Microservices are:  SOA done right?  SOA but with a bounded context? SOA Microservices Integrates multiple applications Multiple microservices = one app ESB smart endpoints, dumb pipes SOAP, XML, WSDL etc REST, JSON etc
  13. 13. Shaun Abram 13 Who is using Microservices? Many large scale web sites have evolved from monolith to microservices  Amazon  100-150 services per page  Netflix  Extensive users and contributors  Chaos Monkey, Janitor Monkey, see  TicketMaster  Boardroom agility -> quickly react to the marketplace
  14. 14. Shaun Abram 14 Microservice best practices  Separate codebases  Use monitoring  Built in health checks  Provide standard templates  Support multiple versions
  15. 15. Shaun Abram 15 Microservices Summary + Attractive alternative to monoliths + Independently built and deployed stacks + Allows 'deploy early, deploy often' - No silver Bullet! - Coordination of dozens of services is difficult - Integration, deployment, monitoring all more complex - Need cross functional teams skilled in Devops Start with monoliths; Migrate slowly "With cautious optimism, we think microservices can be a worthwhile road to tread"
  16. 16. Shaun Abram 16 An introduction to Microservices and REST  Microservices  REST
  17. 17. Shaun Abram 17 REST  A brief history of www  What was learned?  What is REST? Constraints!  HTTP  HATEOAS
  18. 18. Shaun Abram 18 Representational state transfer REST is an architectural style (set of constraints) For example:  Relies on a stateless, client-server communications protocol (think: HTTP)  Uniform interfaces (think: URIs, or links)  Interaction with resources via standard methods (think: HTTP verbs) Pretty URLs? Alternative to RPC or SOAP? Yes, but so much more…
  19. 19. Shaun Abram 19 A brief History of the World Wide Web  Tim Berners-Lee first proposed the www (1989)  HTTP – Formal set of rules for exchanging information over web – Enables retrieval of linked resources  HTML – Ability to format docs and link to other docs/resources  URI – Kind of “address”, unique to each resource
  20. 20. Shaun Abram 20 A brief History of the World Wide Web  HTTP 0.9 (1991)  only one method: GET  HTTP 1.0 (1996)  From trivial request/response true msging protocol  HTTP 1.1 (1996) What version of HTTP are we on today? Still 1.1, over 25 years later!
  21. 21. Shaun Abram 21 REST: Lessons learned  Fielding involved since infancy of web – HTTP, HTML, URIs, Apache HTTP Server  Experienced first hand its rapid growth (as user+arch)  Understood the reasons for its success  Begin to write about lessons learned  Web arch principles -> framework of constraints Architectural Styles and the Design of Network-based Software Architectures (2000) “REST has been used to guide the design and development of the architecture for the modern Web”.
  22. 22. Shaun Abram 22 REST So, what is REST An architectural style A set of constraints Why constraints?
  23. 23. Shaun Abram 23 REST Constraints 1. Client Server 2. Stateless 3. Cache 4. Uniform Interface 5. Layered System 6. Code-On-Demand REST doesn't have to use HTTP, but… (alternatives? Gopher, waka, SPDY)
  24. 24. Shaun Abram 24 REST Constraints 1. Client Server 2. Stateless 3. Cache 4. Uniform Interface 5. Layered System 6. Code-On-Demand
  25. 25. Shaun Abram 25 REST Constraints 1. Client Server Separating UI concerns from data storage concerns  Improves portability of UI across platforms  Improves scalability by simplifying server components  Allows components to evolve independently Http:  A client server protocol  E.g. browser <-> serving content (Apache, IIS, Nginx)  Or anything in the Internet of Things
  26. 26. Shaun Abram 26 REST Constraints 1. Client Server 2. Stateless 3. Cache 4. Uniform Interface 5. Layered System 6. Code-On-Demand
  27. 27. Shaun Abram 27 REST Constraints 2. Stateless  Communication must be stateless!  Each request must contain all required info  No state on server Advs:  Reliability – easier to recover from failures  Scalability & simplification HTTP:  A stateless protocol  Can circumvent by using cookies, sessions, but…
  28. 28. Shaun Abram 28 REST Constraints 1. Client Server 2. Stateless 3. Cache 4. Uniform Interface 5. Layered System 6. Code-On-Demand
  29. 29. Shaun Abram 29 REST Constraints 3. Cache  Response can be labeled as cacheable or not  If cacheable, client cache can reuse response HTTP:  Supports caching via three basic mechanisms:  freshness  validation  invalidation
  30. 30. Shaun Abram 30 REST Constraints 1. Client Server 2. Stateless 3. Cache 4. Uniform Interface 5. Layered System 6. Code-On-Demand
  31. 31. Shaun Abram 31 REST Constraints 4. Uniform Interface  Central feature!  Impls decoupled from the services they provide  Encourages independent evolvability
  32. 32. Shaun Abram 32 REST Constraints 4. Uniform Interface a) Identification of resources b) Manipulation of resources through these representations c) Self-descriptive messages d) Hypermedia as the engine of application state (HATEOAS)
  33. 33. Shaun Abram 33 REST Constraints 4. Uniform Interface In plain English…  Common to use interfaces to decouple client from impl  Goal: Simple Interface, full functionality, hide complexity e.g. GUI  REST/HTTP achieves this!  Combine with HTTP (methods, media types)  Powerful, simple, widely understood
  34. 34. Shaun Abram 34 REST Constraints 1. Client Server 2. Stateless 3. Cache 4. Uniform Interface 5. Layered System 6. Code-On-Demand
  35. 35. Shaun Abram 35 REST Constraints 5. Layered System  Allows an architecture to be composed of layers  Constraining component behavior  Each component cannot “see” beyond immediate layer  Client unaware if connected to the end or intermediary improve scalability (e.g. load-balancing), security  HTTP supports layering via proxy servers and caching.
  36. 36. Shaun Abram 36 REST Constraints 1. Client Server 2. Stateless 3. Cache 4. Uniform Interface 5. Layered System 6. Code-On-Demand
  37. 37. Shaun Abram 37 REST Constraints 6. Code-On-Demand (optional)  Client functionality can be extended (scripts/applets)  Allows server to decide how some things will be done  For example  client requests a resource,  server returns resource with some JavaScript
  38. 38. Shaun Abram 38 HTTP  Requests & Responses  Methods  Status codes
  39. 39. Shaun Abram 39 HTTP Request Example HTTP request: GET /index.html HTTP/1.1 Host: This is made up of the following components:  Method: GET  URI: /index.html  Version: HTTP/1.1  Headers: Host:  Body: empty in this example
  40. 40. Shaun Abram 40 HTTP Response Example HTTP response: HTTP/1.1 200 OK Version/Status code; Reason phrase Date: Mon, 23 May 2005 22:38:34 GMT HEADERS Server: Apache/ (Unix) (Red-Hat/Linux) Last-Modified: Wed, 08 Jan 2003 23:11:55 GMT ETag: "3f80f-1b6-3e1cb03b” Content-Type: text/html; charset=UTF-8 Content-Length: 131 Accept-Ranges: bytes Connection: close <html> … </html> BODY
  41. 41. Shaun Abram 41 HTTP Methods Safe and Idempotent methods Safe methods  Do not modify resources – retrieval only  HEAD, GET, OPTIONS and TRACE Idempotent methods  Can be called many times, same outcome  GET, HEAD, PUT and DELETE  Also, OPTIONS and TRACE are inherently idempotent
  42. 42. Shaun Abram 42 HTTP Methods Which methods are safe AND idempotent?
  43. 43. Shaun Abram 43 Common HTTP Methods  GET  DELETE  PUT  POST
  44. 44. Shaun Abram 44 Common HTTP Methods  GET  Retrieve the resource identified by the URI  DELETE  Delete the resource identified by the URI
  45. 45. Shaun Abram 45 Common HTTP Methods  PUT  Store the supplied entity under the supplied URI  If already exists, update  If not create with that URI  POST  Request to accept the entity as a new subordinate of the resource identified by the URI  For example – Submit data from a form to a data-handling process; – Post a message to a mailing list or blog  In plain English, create a resource
  46. 46. Shaun Abram 46 PUT vs POST: What is the difference?! Some rules of thumb:  PUT is for update; POST is for create  PUT idempotent; POST is not;  Who creates the URL of the resource?  PUT when you know the URL to be created  POST when server decides the URL for you  Don’t use PUT, always POST (post events instead)? Short answer? Use you best judgment!
  47. 47. Shaun Abram 47 Uncommon HTTP Methods  HEAD  OPTIONS  TRACE  CONNECT
  48. 48. Shaun Abram 48 Uncommon HTTP Methods  HEAD  Like GET but without the body  Used for obtaining meta-information about the entity  Useful for testing links, e.g. for validity, accessibility  OPTIONS  Request about the capabilities of a server  e.g. request a list of supported HTTP methods  Possible response: 200 OK; Allow: HEAD,GET,PUT,DELETE  Useful but not widely supported
  49. 49. Shaun Abram 49 Uncommon HTTP Methods  TRACE  Used to invoke a remote loop-back of the request  Plain English: Echoes back request to see what changes have been made by intermediate servers  Often disabled for security  CONNECT  For use with a proxy that can dynamically switch to being a tunnel  Typically for tunneling HTTPS through HTTP connection
  50. 50. Shaun Abram 50 HTTP response codes You submit a request to the server; At a minimum, the server will return a status code The first digit of the status code specifies one of five classes of response The bare minimum for an HTTP client is that it recognizes these five classes
  51. 51. Shaun Abram 51 HTTP response codes Code Meaning Plain English (From user perspective) 1xx Informational; indicates a provisional response, e.g. 100 OK so far and client should continue with the request 2xx Successful All good 3xx Redirection Something moved 4xx Client Error You messed up 5xx Server Error We messed up
  52. 52. Shaun Abram 52 Hypermedia as the engine of application state (HATEOAS) Terminology:  URI and URL  Hypertext  Multimedia  Hypermedia
  53. 53. Shaun Abram 53 Hypermedia as the engine of application state (HATEOAS) Clients know fixed entry points to the app Transition (states) by using those links + more If you think of Hypermedia as simply links, then HATEOAS is simply using the links you discover to navigate (or transition state) through the application. Applies to human or software users
  54. 54. Shaun Abram 54 Why use REST?  You have a need to inter process communication  For example, client/server  Options: RPC, SOAP/WebServices, Sockets?  Or…
  55. 55. Shaun Abram 55 REST Summary  An architectural style, or a set of constraints  Captures the fundamental principles of the Web  Tried & tested architectural approach  Emphasizes simplicity, and existing web technologies Key points:  Uniform interfaces: All resources are identified by URIs  HTTP Methods: to manipulate all resources  Stateless: There is no state on the server
  56. 56. Shaun Abram 56 Microservices & REST Microservices:  A small, focused, loosely coupled service  Can be developed, deployed, upgraded independently How to communicate with and between Microservices? REST & HTTP!  Uniform interfaces accessing stateless services  Allows services to be independent of clients
  57. 57. Shaun Abram 57 How to build RESTful Microservices in Java?  JAX-RS  Java API for RESTful Web Services  Java EE spec  Implementations include: – Jersey (reference implementation from Oracle) – Apache CXF – RESTeasy  Spring MVC REST  Not JAX-RS compliant, but…  Still REST compliant  Easy MVC integration
  58. 58. Shaun Abram 58 Use Embedded Servers?  Service runs ‘out of the box’  No need to deploy to separate server  Deploy to a fresh server straight from VCS
  59. 59. Shaun Abram 59 Spring Boot  “Starter Packs” of dependencies  Convention-based configuration  Production-ready services such as metrics, health, app lifecycle.  No code generation, just a pom dependency  Spring 4 only  Maven and Gradle plugins
  60. 60. Shaun Abram 60 DropWizard  Packages together libraries from the Java ecosystem  Jetty for HTTP  Jersey for REST  Jackson for JSON  Lets you focus on getting things done  Can be used with or instead of Spring Boot
  61. 61. Shaun Abram Questions?
  62. 62. Shaun Abram 62