rest - blogs. · pdf file soap: rpc via http, uses http as tunnel not descriptive: ... a lot...

RESTA brief introduction

Juergen Brendel

All contents Copyright © 2010, Mulesoft Inc. 2

What is it good for?

► Something with networks: APIs

Interactions

Distributed systems?


Getting more popular


Confusion

► So, like XML-RPC, RMI, CORBA?

Not really...

► Many “REST APIs” are not REST

( HTTP != REST)


The origins of REST


The origins of REST

Roy FieldingRoy Fielding


The origins of REST

► 1999: RFC 2616: HTTP/1.1

► 2000: PhD thesis

Architectural Styles and theDesign of Network-basedSoftware Architectures

► Defined “REST”

REpresentationalState Transfer

Roy FieldingRoy Fielding


REST: What is it NOT?

► Protocol

► API

► Framework

► Product

► Technique

► 1:1 replacement for RPC


What is REST?

► “Architectural style”

► Constraints and principles


Goals

► Work WITH the web, not against it

► Trade scalability for latency

► Intermediaries as active participants Caches

Proxies

Load balancers

Generic servers


(interlude: the HTTP header)

You enter this:

http://www.foo.com/xyz/bar?name=Smith



You enter this:


Browser connects and sends:

GET /xyz/bar?name=Smith HTTP/1.1Host: www.foo.comUseragent: Mozilla/5.0, ...Accept: */*...



You enter this:




“Verb”: HTTP method(what are we doing)



You enter this:




“Noun”: Path of URL(what are we operating on)


REST principles, part 1

► Well known actions ('verbs')

► Resources ('nouns')

► HTTP?


Names and standard methods

SOAP: RPC via HTTP, uses HTTP as tunnel



POST /myService HTTP/1.1Host: www.foo.com ...

<?xml version="1.0"?><soap:Envelope xmlns:soap="http://www.w3.org/2001/12/soapenvelope" soap:encodingStyle="http://www.w3.org/2001/12/soapencoding"> <soap:Body xmlns:m="http://www.foo.com/customer"> <m:GetCustomer> <m:CustomerName>Smith</m:CustomerName> </m:GetCustomer></soap:Body> </soap:Envelope>




POST /myService HTTP/1.1Host: www.foo.com ...

<?xml version="1.0"?><soap:Envelope xmlns:soap="http://www.w3.org/2001/12/soapenvelope" soap:encodingStyle="http://www.w3.org/2001/12/soapencoding"> <soap:Body xmlns:m="http://www.foo.com/customer"> <m:GetCustomer> <m:CustomerName>Smith</m:CustomerName> </m:GetCustomer></soap:Body> </soap:Envelope>


Not descriptive:Same for each request

Why is that a problem?



http://foo.com/srv?method=GetCustomer&name=Smith

Better, but still only uses HTTP as tunnel





http://foo.com/srv?method=DeleteCustomer&name=Smithhttp://foo.com/srv?method=GetCustomer&name=Smith

cachecache??





http://foo.com/srv?method=MakeCustomer& name=Smith& first=John

http://foo.com/srv?method=DeleteCustomer&name=Smithhttp://foo.com/srv?method=GetCustomer&name=Smith

cachecache??reloadreload??



GET /customer/Smith HTTP/1.1Host: foo.comAccept: application/json

RESTful (retrieving record)

http://foo.com/customer/Smith






A collection






ID of itemin collection






{ “name” : “Smith”,

“first” : “Frank”}



PUT /customer/Smith HTTP/1.1Host: foo.comContenttype: application/json

{ “name” : “Smith”,

“first” : “Frank”}

RESTful (updating record)




DELETE /customer/Smith HTTP/1.1Host: foo.com

RESTful (deleting record)




POST /customer HTTP/1.1Host: foo.comContenttype: application/json

{ “name” : “Smith”, “first” : “John”}

RESTful (creating record)

http://foo.com/customer/



GET /customer HTTP/1.1Host: foo.comContenttype: application/json

RESTful (get collection)

http://foo.com/customer/

{ “Smith” : { “link” : “/customer/Smith”, “method” : “GET” }, “Jones” : { “link” : “/customer/Jones”, “method” : “GET” }}



► “Resources” not “Actions”

► Proper use of HTTP methods



► “Resources” not “Actions”

► Proper use of HTTP methods

► Stateless

► Representations / media types

► Links (HATEOAS)


Representations


GET /customer/Smith HTTP/1.1

Accept: application/xml

<person> <name>Smith</name> <first>John</first></person>

GET /customer/Smith HTTP/1.1

Accept: application/json

{ “name” : “Smith”, “first” : “John”}


Media types

► Preferred: IANA registered MIME types Think about intermediaries

► If necessary: Custom type


HATEOAS

“Hypermedia as theEngine of Application State”

Or:

“There are links in the representation”


HATEOAS

► Resources carry links Describe how state of resource can be changed

► Dynamic

► Example: Web pages


Example: Collection

{“entries” : {

“Smith” : { “link” : “/customers/Smith”, “method” : “GET” },“Jones” : { “link” : “/customers/Jones”, “method” : “GET” }

},“links” : [

{ “link” : “/customers”, “rel” : “add”, “method” : “POST” },{ “link” : “/customers”, “rel” : “list”, “method” : “GET” }

]}


Example: Order record

{ “id” : 6227, “customer” : { “link” : “/customer/Smith”, “method” : “GET” }, “item” : { “link” : “/items/4552”, “method” : “GET” }, “quantity” : 4, “amount” : 5622.95, “links” : [

{ “link” : “/orders/6227”, “rel” : “edit”, “method” : “PUT” },{ “link” : “/orders/6227/status”, “rel” : “status”, “method” : “GET” }

]}


Example: Order record

{ “id” : 6227, “customer” : { “link” : “/customer/Smith”, “method” : “GET” }, “item” : { “link” : “/items/4552”, “method” : “GET” }, “quantity” : 4, “amount” : 5622.95, “links” : [

{ “link” : “/orders/6227”, “rel” : “edit”, “method” : “PUT” },{ “link” : “/orders/6227/status”, “rel” : “status”, “method” : “GET” }

]}

Could disappear,if order is finalized


Benefit: Scalability

► Performance: Caches / load-balancers

Stateless

Agility

► Adoption: Bookmarkable links

Any HTTP enabled client


Benefit: Simplicity / reuse

► Development: Open source app frameworks / tools

► Testing: Click it!

► Operation: Scheduling? cron + curl

Caching? squid, varnish

Security? ssl, HTTP-auth, apache, nginx, etc.


REST challenges

► Focus on resource not action No 1:1 mapping to OO

► Requires rethinking A lot of investment into methods and RPC

► Scalability, not latency

► Frameworks Often low-level


The end

juergen.brendel@mulesoft .com

@BrendelConsult

rest - blogs. · pdf file soap: rpc via http, uses http as tunnel not descriptive: ... a lot...

Documents