1. REST
Introduction
Christopher Jimenez

2. ● Short of Representation State Transfer(Roy
Thomas)
● A style of software arquitecture (Client-
Server)
● It’s the way the Web already works, just
formalized a bit and with some do’s and don’
ts.
What is REST??

3. What’s a Web Service?
● A web service is just a web page meant for a
computer to request and process
● More precisely, a Web service is a Web
page that’s meant to be consumed by an
autonomous program as opposed to a Web
browser or similar UI tool

4. Key REST principles
● Give every “thing” an ID
● Link things together
● Use standard methods
● Resources with multiple
representations
● Communicate statelessly

5. Give every “thing” an ID

6. Give every “thing” an ID
● A “Thing” is actually a
resource
● URIs can also be IDs
● URIS should be human-
readable

7. Give every “thing” an ID
http://example.com/customers/1234
http://example.com/orders/2007/10/776654
http://example.com/products/4554

8. Collection of “things”
http://example.com/customers/
http://example.com/orders/2007/11
http://example.com/products?color=green

9. To Summarize!!
Use URIs to identify everything that
merits being identifiable, specifically, all
of the “high-level” resources that your
application provides, whether they
represent individual items, collections
of items, virtual and physical objects, or
computation results.

10. Link things Together

11. Link things together
● At its core is the concept of hypermedia, or
in other words: the idea of links
● Links are something we’re all familiar with
from HTML, but they are in no way restricted
to human consumption.

12. Link things together
<order self='http://example.com/customers/1234' >
<amount>23</amount>
<product ref='http://example.com/products/4554' />
<customer ref='http://example.com/customers/1234' />
</order>

13. Result!
The beauty of the link approach using URIs is
that the links can point to resources that are
provided by a different application, a different
server, or even a different company on another
continent

14. Use Standard Methods

15. Use Standard methods
● HTTP calls these Verbs
● The two everyone knows are GET and
POST
● But there is also, PUT, DELETE, HEAD and
OPTIONS

16. Use Standard Methods

HTTP Method CRUD
Guaranties.
POST CREATE Create -
GET RETRIEVE Retrieve Safe, Cacheable,Idempotent
PUT UPDATE Update Idempotent
DELETE DELETE Delete Idempotent

17. Safe??

18. Safe?
● Takes no action other than retrieval
● User did not request the side-effects,
so therefore cannot be held
accountable for them.

19. Cacheable?

20. Cacheable?
● GET supports very efficient and
sophisticated caching
● In many cases, you don’t even have to send
a request to the server

21. WTF! Idempotent?

22. WTF! Idempotent?
● (Idempotent) unchanged in value following
multiplication by itself
● If you issue a GET request and don’t get a
result, you might not know whether your
request never reached its destination or the
response got lost on its way back to you
● The idempotence guarantee means you can
simply issue the request again

23. Standard Methods
class Resource {
Resource(URI u);
Response get();
Response post(Request r);
Response put(Request r);
Response delete();
}

24. Example Not REST
Orders & Customers

25. RESTful Aproach
The Rest Way

26. Multiple representations
Multiple standards
● XML
● JSON
● V-CARD
● RSS

27. Multiple representations
http://www.pixel16.com/callmenot/phones/20.xml
<?xml version="1.0" encoding="UTF-8"?>
<response>
<phone>
<Phone>
<id>18</id>
<phone>3434343</phone>
<description>asf</description>
<created>2013-07-10 17:04:23</created>
<modified>2013-07-10 17:04:23</modified>
</Phone>
</phone>
</response>

28. Multiple representation
www.pixel16.com/callmenot/phones/18.json
{
"phone":{
"Phone":{
"id":"18",
"phone":"3434343",
"description":"asf",
"created":"2013-07-10 17:04:23",
"modified":"2013-07-10 17:04:23"
}
}
}

29. Communicate statelessly

30. Statelessly
● REST mandates that state be either turned
into resource state, or kept on the client
● The server should not have to retain some
sort of communication state for any of the
clients it communicates with beyond a single
request.

31. Statelessly
● Scalability — the number of clients interacting would
seriously impact the server’s footprint if it had to keep
client state
● A client could receive a document containing links from
the server, and while it does some processing, the
server could be shut down, its hard disk could be ripped
out and be replaced, the software could be updated and
restarted — and if the client follows one of the links it
has received from the server, it won’t notice.

32. Authentication?

33. Authentication
● HTTP basic auth over HTTPS
● Session via Cookies
● Query Authentication

34. HTTP basic auth over
HTTPS
● Based on the standard HTTPS protocol
● Awful authentication window displayed on
the Browser
● Some server-side additional CPU
consumption
● User-name and password are transmitted
(over HTTPS) into the Server

35. Session via Cookies
● Is not truly Stateless
● The cookie technique itself is HTTP-linked,
so it's not truly RESTful, which should be
protocol-independent.

36. Query Authentication
Consists in signing each RESTful request via
some additional parameters on the URI.
Server-side data caching can be always
available(cache the responses at the SQL
level, not at the URI level)

37. Amazon Example

38. Amazon Example

39. Useful Resources

40. Google TeckTalk
How To Design A Good API and Why it Matters

41. Questions?