Loading presentation...

Present Remotely

Send the link below via email or IM

Copy

Present to your audience

Start remote presentation

  • Invited audience members will follow you as you navigate and present
  • People invited to a presentation do not need a Prezi account
  • This link expires 10 minutes after you close the presentation
  • A maximum of 30 users can follow your presentation
  • Learn more about this feature in our knowledge base article

Do you really want to delete this prezi?

Neither you, nor the coeditors you shared it with will be able to recover it again.

DeleteCancel

Make your likes visible on Facebook?

Connect your Facebook account to Prezi and let your likes appear on your timeline.
You can change this under Settings & Account at any time.

No, thanks

REST

What is REST; why are we using it?
by

Igo Coelho

on 20 November 2013

Comments (0)

Please log in to add your comment.

Report abuse

Transcript of REST

What is REST?
Retrieving a resource
Specifying media type
Creating a resource
Creating a resource II
Few verbs
Many resources
Many verbs
Few resources
REST
SOAP
Compared with SOAP
A style of software architecture concerned with the management of
- Giving business artifacts long-lived URIs feels good

- Fits well withing our service oriented approach (we can reference 'external' resources by their URI)

- It's hackable, hopefully leading to familiarity and innovation

- It's emminently interoperable

- Allows us to capitalise on existing tools and infrastructre. (Cacheing, browsers, CURL, fiddler ...)
RESOURCES
What's a resource?
Anything, really. In our world
orders
products
invoices
albums
users
retailers
are all resources
Resources are identified
using URIs...
http://res.linn.co.uk/orders/512
http://res.linn.co.uk/products/klimax-kontrol
http://res.linn.co.uk/invoices/1265/delivery-address
Performing a search
whose state is controlled via the transfer of
REPRESENTATIONS
and a representation?
A document that describes the current or intended state of a resource. It could be XML, or JSON, or a FLAC file or a bitmap, or anything sensible
<user>
<firstname>sandy</firstname>
<lastname>cormie</lastname>
<address>
<line1>Glasgow Road</line1>
<line2>Waterfoot</line2>
<city>Glasgow</city>
<postcode>G76 0EQ</postcode>
</address>
</user>
{ "title": "Helplessness Blues",
"titleArtist": "Fleet Foxes",
"catalogueNumber": "BU5153",
"tracks" : [ { "title" : "Montezuma", "ISRC": 51236 },
{ "title" : "Bedouin Dress", "ISRC": 51256 },
... ]
}
Hence
RE
presentational
S
tate
T
ransfer
Protocols
REST isn't protocol specific, but is commonly implemented over HTTP.
HTTP provides
URIs
well understood response codes
a useful set of verbs
support for varied media-types (aka MIME types)
Examples
SIMPLE
TRICKIER
REQUEST

GET /retailers/512 HTTP/1.1
Host: res.linn.co.uk


REPLY

HTTP/1.1 200 OK
Content-Type: application/xml

<retailer>
<name>Weasel Audio Ltd>
<address>...</address>
<imageUrl>http://static.linn.co.uk/images/retailers/512</imageUrl>
<openingHours>...<openingHours>
</retailer>
REQUEST

PUT /releases/CKD412 HTTP/1.1
Host: res.linn.co.uk
Content-Type: application/xml

<release>
<title>Disco Badger</title>
<titleArtist>Maeve O'Boyle</titleArtist>
<tracks>...</tracks>
</release>


REPLY

HTTP/1.1 201 Created
Location: /releases/CKD412
Content-Type: application/xml

<release>
<link rel="self" href="/releases/CKD412" />
<title>Disco Badger</title>
<titleArtist>Maeve O'Boyle</titleArtist>
<tracks>...</tracks>
</release>
REQUEST

POST /orders HTTP/1.1
Host: res.linn.co.uk
Content-Type: application/xml

<order>
...
</order>


REPLY

HTTP/1.1 201 Created
Location: /orders/6346
Content-Type: application/xml

<order>
...
</order>
REQUEST

GET /retailers/512 HTTP/1.1
Host: res.linn.co.uk
Accept-Content: application/json


REPLY

HTTP/1.1 200 OK
Content-Type: application/json

{ "name" : "Weasel Hifi Ltd",
"address" : { ... },
"imageUrl": "http://static.linn.co.uk/images/retailers/512",
"openingHours" : { ... }
}
REQUEST

GET /retailers?name=Weasel HTTP/1.1
Host: res.linn.co.uk


REPLY

HTTP/1.1 200 OK
Content-Type: application/xml

<retailers count="2">
<retailer>
<link rel="self" href="/retailers/142" />
<name>Weasel Hifi Ltd>
<address>...</address>
<imageUrl>http://static.linn.co.uk/images/retailers/142</imageUrl>
<openingHours>...<openingHours>
</retailer>
<retailer>
<link rel="self" href="/retailers/63" />
<name>Weasel Audio Ltd>
<address>...</address>
<imageUrl>http://static.linn.co.uk/images/retailers/63</imageUrl>
<openingHours>...<openingHours>
</retailer>
</retailers>
Long running operations
Cross-resource transactions
Create a resource to represent the operation. The resource may be temporary, if desired.
REQUEST

POST /releases/CKD412/transcoding-request HTTP/1.1
Host: res.linn.co.uk

<transcodingRequest>
<format>Studio Master</format>
</transcodingRequest>


REPLY

HTTP/1.1 202 Accepted
Location: /releases/CKD412/transcoding-request/1
Content-Type: application/xml

<transcodingRequest>
<format>Studio Master</format>
<status>Pending</status>
<requested>2011-09-23-09:20</requested>
</transcodingRequest>
How does it work?
We interact with resource using HTTP verbs.
GET is used to retrieve a resource. GET is "safe"; issuing a GET request cannot modify the state of a resource.
PUT is used to create or modify a resource at a known URI. It is "idempotent", you can issue the same PUT request multiple times and achieve the same outcome.
POST can be used to add a resource to a collection, or to modify an existing resource. Is it NOT idempotent.
DELETE is used to delete a resource. It is idempotent.
idempotence helps make a system resilient
Is that it?
Not quite...
RICHARDSON MATURITY MODEL
The
measures the adpotion of RESTful practices. It defines 4 levels...
Level 0
HTTP
Level 1
Level 2
Level 3
Resources
Verbs
Hypermedia
Use hypermedia to control state
Consider the following state model for an order...
new
pending
being built
awaiting despatch
complete
cancelled
awaiting payment
Include hyperlinks within the representation of the resource to allow the client to discover what state changes are permissable (HATEOAS)
<order>
<account>..</acount>
<orderlines>...<orderlines>
<state>pending<state>
<link rel="rels/orders/cancel" href="http://linn.co.uk/orders/14" />
<link rel="rels/orders/accept-payment" href="http://linn.co.uk/orders/14/payment" />
<link rel="rels/orders/build" href="http://linn.co.uk/orders/14/build-requests" />
</order>
The client still has to work out which verb to use...
REST
Why do we like it?
Users Service
Orders Service
Retailers Service
http://res.linn.co.uk/users/142

<user>
<firstname>Sandy</firstname>
<surname>Cormie</cormie>
<address>...</address>
...
</user>
http://res.linn.co.uk/retailers/667

<retailer>
<name>Weasel Audio</retailer>
<address>...</address>
...
</retailer>
http://res.linn.co.uk/orders/422

<order>
<account>http://res.linn.co.uk/users/142</account>
<orderlines>...</orderlines>
...
</order>


http://res.linn.co.uk/orders/262

<order>
<account>http://res.linn.co.uk/retailers/667</account>
<orderlines>...</orderlines>
...
</order>
REQUEST

GET /releases/CKD412/transcoding-request/1 HTTP/1.1
Accept-Content: application/xml
Host: res.linn.co.uk


REPLY

HTTP/1.1 200 OK
Content-Type: application/xml

<transcodingRequest>
<status>In progress</status>
...
</transcodingRequest>




HTTP/1.1 303 See Other
Location: /releases/CKD412/transcodes/FLAC/1

<transcodingRequest>
<status>Complete</status>
...
</transcodingRequest>
The client is then free to issue GET requests on the resource to establish its status
or upon completion...
Again, the answer is to create a new resource that wraps the transaction.
To transfer money from bank account 125 to bank account 55, create a new transfer resource.
REQUEST

POST /transfers HTTP/1.1
Host: www.linnbank.com
Content-Type: application/xml

<transfer>
<source>/accounts/125</source>
<target>/accounts/55</target>
<amount>150</amount>
</transfer>

REPLY

HTTP/1.1 201 Created
Content-Type: application/xml
Location:http://linnbank.com/transfers/1

<transfer>
<source>/accounts/125</source>
<target>/accounts/55</target>
<amount>150</amount>
</transfer>
Software Architecture
business
logic
persitence
data
store
restful
interface
The architecture of one service hosting multiple, related resources.
The business logic is ignorant of the restful interface
Each service will have its own, dedicated database
This layer publishes the functinoality of the service as resources
We are building a platform of services, each specialising is a particular facet of the business.
End-Users
Orders
Retailers
Music
Products
Stores
There are going to be LOTS of services
Client application X
Client application Y
Web application Z
Full transcript