Being in a State of REST

being in a state of RESTAslam Khan@aslamkhn

[email protected]

mailto:[email protected]


What’s not on the agenda

sniper shots

grenades strapped to chest rants

mass hypnosis

Let’s take a few steps back

I did do this...create quote

quoteservice

POST /quoteService<QuoteRequestMessage ...

200 OK<Quote ...

and this … accept quote

quoteservice

POST /quoteService<AcceptQuoteMessage ...

200 OK<StatusMessage ...

and this … exceptions

quoteservice


200 OK<Error ...

slinging XMLRPC == true

REST == false

REST(0)

no uniformity => accidental complexity

quoteservice


200 OK<Quote ...

quoteservice



quoteservice


200 OK<Error ...

We should use

standards, right?

do contract firstxml schema + wsdl + soap + ...

enter WS_*

feels like static typing in a dynamic world

ptaaanngg!! ... oops … sniper shot

slinging XMLwith envelopes

Complex remote access protocol

WS-*

toolsets are symptomatic of the complexity

quoteservice


200 OK<Quote ...

quoteservice



quoteservice


200 OK<Error ...

This is not my idea of software development

Next attempt … many endpointsPOST /customer/176202?fromDate...

200 OK<Quote id="Q91827"

/customer

/quote

POST /quote?ref=Q91827

200 OK<Policy...

same thing … just friendlyPOST <FindQuote fromDate="...


/customer/176202

/quote/Q91827

POST <AcceptQuote

200 OK<Policy...

but I can almost imagine the modelcustomer

quote

findQuote(...)

accept(...)policy

*

resourcesaddressability

REST(1)

oo-ish but no uniformity

GET /customer/176202/quotes?from...


/customer

/quote

POST /quote/Q91827<Acceptance ...

201 OKLocation: /policy/PX81730Z9...<Policy id="PX81730Z9...

How about this … verb idioms

Predictability is more important than

POST

PUT

DELETE

create

update

delete

don’t be dogmatic, be pragmatic

think safe vs unsafe and side-effects

GET retrieve

Again, being predictable

201

409

401

created

conflict

unauthorised

uniformity is a powerful force

... ...

HTTP Verbs+response codes

REST(2)

uniformity + unsafe vs safe operationsbut dumping a ton of URI’s on your friends is not very nice

This is the next stepGET /customer/176202

200 OK<Customer id="Q91827" ... <links> <link rel='find quotes' uri='/quotes/176202"/> <link rel='policy' uri='/policy/PX81730Z9"/>

/customer

and so on ...GET /quotes/Q91827

200 OK<Quotes customer="176202" ... <quote id="Q91827" <links> <link rel='accept quote' uri='/blahblah?id="Q91827"/> <link rel='cancel quote' uri='/ushoqwbyw/198n392/>

state changed?GET /quotes/Q91827

200 OK<Quotes customer="176202" ... <quote id="Q91827" <links> <link rel="self" uri='/quote/Q91827"/> </link>

Hypermedia(HATEOS)

REST(3)

HTTP idioms + media-types + hypermedia

REST(1)

REST(2)

REST(3)

REST(0)

vanilla Rails somewhere here}Richardsonmaturity model

this is the signal

in the noise!

But it is always about design.

How do you design when REST

is your architectural style?

REST is not the end goal, it is

actually your starting position.

And it’s not for everything.

REST(1)

REST(2)

REST(3)

REST(0)

This is a

design choice.ranges from exploiting HTTP

to honoring HTTP

Some context first

Design, for me, is just answering two questions.

1. Does that thing express its intention?

2. Where should I put that thing?

5 Design things to think about

resource overloading is not reuse

doubling up a resource to serve more than

its single purpose is more likely to introduce

accidental complexity than visible benefit.

there is no cost to having lots of resources(if there is, you have a bigger problem)

+

the set of resources is open ended

Refer to self is importantPOST /customer<customer> ... </customer>

reduce URI explosions

200 OK<customer id=194839> ... <links> <link rel=”self” uri=”/customer/194839> </links></customer>

no need to expose /customer/{customer_id}

Jou ma se State!

app state can be inferred

customer

quote

findQuote(...)

accept(...)policy

*

domain state resource state application state

Search

/policy /claim /customer

Find all resources where

there is an email address

“[email protected]”

Find all claims that are

approved but unpaid and

where the policy is paid up

create another resource for the result … and then?



Domain : Resource Impedancevehicle

movement*

position

{ registration : Ca28382, last_movement: { odo: 78282, lat: ... } links { ... }}

GET /lastmovement/CA28382

?

aggregates ==

resources?not necessarily

entities == resources?it is still a bi-directional mapping

problemno domain model?where should we model

behavior?

def valuable?(signal, noise)(signal.power/noise.power) > 1

end

valuable?(hype, design).should == falsevaluable?(design, hype).should == true

obligatory ruby code slide

Thanks, and so long

Technology

Being in a State of REST