REST and Microservices

Shaun Abram

Shaun Abram

An introduction to

Microservices and REST

November 15th, 2014

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

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

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…

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?

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

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”

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?

Shaun Abram 9

Advantages of microservices

Small?

Single, focused purpose

Independently deployable

Independently scalable, resilient

Shaun Abram 10

Advantages of microservices

Small?

Single, focused purpose

Independently deployable

Independently scalable, resilient

Independent technology stack

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

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

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 netflix.github.io.

TicketMaster

Boardroom agility -> quickly react to the marketplace

Shaun Abram 14

Microservice best practices

Separate codebases

Use monitoring

Built in health checks

Provide standard templates

Support multiple versions

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"

Shaun Abram 16

An introduction to Microservices and REST

Microservices

REST

Shaun Abram 17

REST

A brief history of www

What was learned?

What is REST? Constraints!

HTTP

HATEOAS

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…

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

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!

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”.

Shaun Abram 22

REST

So, what is REST

An architectural style

A set of constraints

Why constraints?

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)

Shaun Abram 24

REST Constraints

1. Client Server

2. Stateless

3. Cache


5. Layered System

6. Code-On-Demand

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

Shaun Abram 26

REST Constraints

1. Client Server

2. Stateless

3. Cache


5. Layered System

6. Code-On-Demand

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…

Shaun Abram 28

REST Constraints

1. Client Server

2. Stateless

3. Cache


5. Layered System

6. Code-On-Demand

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

Shaun Abram 30

REST Constraints

1. Client Server

2. Stateless

3. Cache


5. Layered System

6. Code-On-Demand

Shaun Abram 31

REST Constraints


Central feature!

Impls decoupled from the services they provide

Encourages independent evolvability

Shaun Abram 32

REST Constraints


a) Identification of resources

b) Manipulation of resources through these

representations

c) Self-descriptive messages

d) Hypermedia as the engine of application state

(HATEOAS)

Shaun Abram 33

REST Constraints


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!

myservice.com/customers/33245

Combine with HTTP (methods, media types)

Powerful, simple, widely understood

Shaun Abram 34

REST Constraints

1. Client Server

2. Stateless

3. Cache


5. Layered System

6. Code-On-Demand

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.

Shaun Abram 36

REST Constraints

1. Client Server

2. Stateless

3. Cache


5. Layered System

6. Code-On-Demand

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

Shaun Abram 38

HTTP

Requests & Responses

Methods

Status codes

Shaun Abram 39

HTTP Request

Example HTTP request:

GET /index.html HTTP/1.1

Host: www.example.com

This is made up of the following components:

Method: GET

URI: /index.html

Version: HTTP/1.1

Headers: Host: www.example.com

Body: empty in this example

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/1.3.3.7 (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

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

Shaun Abram 42

HTTP Methods

Which methods are safe AND idempotent?

Shaun Abram 43

Common HTTP Methods

GET

DELETE

PUT

POST

Shaun Abram 44

Common HTTP Methods

GET

Retrieve the resource identified by the URI

DELETE

Delete the resource identified by the URI

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

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!

Shaun Abram 47

Uncommon HTTP Methods

HEAD

OPTIONS

TRACE

CONNECT

Shaun Abram 48


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

Shaun Abram 49


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

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

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

Shaun Abram 52

Hypermedia as the engine of application state (HATEOAS)

Terminology:

URI and URL

Hypertext

Multimedia

Hypermedia

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

Shaun Abram 54

Why use REST?

You have a need to inter process communication

For example, client/server

Options: RPC, SOAP/WebServices, Sockets?

Or…

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

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

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

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

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

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

Shaun Abram

Questions?

Shaun Abram 62