The document discusses the REST (REpresentational State Transfer) architectural style and how it differs from traditional SOA (Service Oriented Architecture). It outlines the key principles of REST including addressing resources with URIs, using a uniform interface (HTTP methods), stateless communication, and hypermedia as the driver of application state. The document explains how the web exemplifies REST through the use of URLs, HTTP, and standard formats to access and transfer representations of resources.

1. On being RESTful
Fabio Mancinelli
fm@fabiomancinelli

2. What is this talk about?
An introduction to the REST architectural style...
A different way of looking at
Service Oriented Computing

3. What is this talk about?
An introduction to the REST architectural style...
A different way of looking at
Service Oriented Computing
...and some ideas to foster discussion for
finding new research directions! ☺

4. A RESTless world
Also known as “Service Oriented
Architecture”

5. Classic SOA
Service
• Web-services broker
• WSDL
Register Search
• SOAP
• UDDI Service
provider Request
Service
requester

6. Classic SOA
Service
• Web-services broker
UDDI
• WSDL
Register WSDL WSDL Search
• SOAP
• Service Service
SOAP
UDDI
provider Request requester
Web Service

7. Web(?) services
“Definition: A Web service is a software system
designed to support interoperable machine-to-machine
interaction over a network. It has an interface
described in a machine-processable format (specifically
WSDL). Other systems interact with the Web service
in a manner prescribed by its description using SOAP
messages, typically conveyed using HTTP with an XML
serialization in conjunction with other Web-related
standards.”
[W3C, http://www.w3.org/TR/ws-arch/#whatis]

8. WSDL
XML description of the service interface

9. SOAP
• Was “Simple Object Access Protocol”,
sometimes referred as SOA-Protocol
• Simply an XML-based messaging protocol
used mainly as an RPC protocol

10. UDDI
• Universal Description, Discovery and
Integration
• Platform-independent, XML-based registry
for business services
• Accessible via SOAP, provides WSDLs
(... and other complementary information)

11. The WS-* hell
• WS-Policy • WS-Transfer • WS-Federation
Passive Requestor
• WS-PolicyAssertions • WS-I Basic Profile Profile
• WS-PolicyAttachment • WS-I Basic Security • WS-Reliable
Profile Messaging
• WS-SecurityPolicy • WS-Reliability
• WS-BPEL
• WS-Discovery • WS-Atomic
• WS-CDL Transaction
• WS-Introspection
• WS-Security • WS-Business Activity
• WS-Metadata
Exchange • WS-Secure • WS-Notification
Conversation
• WS-Resource • WS-Eventing
Framework • WS-Security Policy
• WS-Eventing • WS-Trust • WS-Management
• WS-Addressing • WS-Federation • WS-Management
Catalog
• WS-Enumeration • WS-Federation Active • WS-Resource Transfer
Requestor Profile

12. The RESTful side
Also known as “The Web”

13. 1989

14. 2008

15. @PHDThesis{REST,
Author = {Roy Thomas Fielding},
Title = {Architectural styles and the design of
network-based software architectures},
Year = {2000},
Publisher = {University of California, Irvine},
}
2000

16. What is REST?
• REpresentational State Transfer
• An architectural style for distributed
hypermedia systems
• A Uniform-Layered-Client-Cache-Stateless-
Server with Code on Demand architectural
style [Fielding2000, Figure 5-8]

17. What is REST?

18. What is REST?
• •Data elements
Resources and identifiers
• Representations
•
•
Metadata
Control data • •Components
User agent
• •Connectors
Client
•
•
Origin server
Gateway
• Server
• Proxy
• Cache
• Resolver
• Tunnel

19. Data elements
• Resources (and resource identifiers)
“Any concept that might be the target of author’s hypertext”, addressable by well
defined resource identifiers and associated to one or more representations
• Representations
A machine-understandable description of the current resource state; typically a
sequence of bytes in a well defined format known as the media-type
• Metadata
Additional data used to provide additional information about a representation, that
cannot be extrapolated from the representation itself
• Control data
Information describing the purpose of a message exchanged between components

20. Connectors
• Client connector
Initiates communication and performs requests
• Server connector
Listens for connections and replies to requests
• Cache connector
Associated to a client or server connector, saves replies to requests for a later usage
• Resolver
Translates resource identifiers to network addresses for the actual communication
• Tunnel
Relays communication across communication boundaries

21. Components
• User agent
Uses a client connector to perform requests and is the final recipient of responses
• Origin server
Uses a server connector for processing requests and providing responses. It is the
source of resource representations and is the entity governing their state
• Proxy
An intermediary entity selected by a client for performance enhancement, data
translation, etc.
• Gateway
An intermediary entity imposed by the network or by the origin server with similar
functions as a proxy

22. REST and the Web
• URLs provide a consistent and accepted
naming scheme for addressing resources
• HTTP provides the uniform interface for
accessing resources
• Standard formats provide widely
understood representations

23. Web Data Elements
REST data element Web instantiation
Resource identifier URL
Representation HTML, JPG, ...
Representation medatada Media-type, last-modification time
Control data if-modified-since, cache-control

24. Web Connectors
REST connector Web instantiation
Client libwww, libwww-perl
Server libwww, Apache API
Cache Browser cache, Akamai
Resolver Bind (DNS)
Tunnel SOCKS, SSL

25. Web Components
REST component Web instantiation
Origin server Apache httpd, Microsoft IIS
User agent Firefox, IE, Safari, ...
Gateway Squid, CGI, ...
Proxy CERN proxy, Gauntlet

26. A twisted perspective
From interfaces to resources

27. REST Key principles
• Addressability
• Uniform interface
• Stateless communication
• Hypermedia As The Engine Of Application
State

28. Addressability
• Using resource URIs to expose interesting
part of system data and state
• All the pages talking about me: http://
www.google.com/search?q=Fabio+Mancinelli
• Introduces nice properties (e.g., easy
communication, bookmarking, caching,
chaining...)

29. Uniform interface
• A single interface is used to access and
manipulate resources
• Well defined semantics
• HTTP is the uniform interface to the web
Verb (method) Semantics Property
GET Retrieve a representation Safe + Idempotent
PUT Store a representation Idempotent
DELETE Delete a resource Idempotent
POST Problems here! A backdoor/mismatch

30. Uniform interface
API1
API2
APIn
API3

31. Uniform interface
Uniform interface

32. Twisted!
OrderManagementService
+ getOrders()
+ submitOrder()
+ getOrdersForCustomers()
+ updateOrder()
+ addOrderItem()
CustomerManagementService
+ cancelOrder()
+ getCustomers()
+ addCustomer()
+ getCustomerDetail()
+ updateCustomer()
+ deleteCustomer()
[Example taken from http://www.infoq.com/articles/rest-introduction by Stefan Tilkov]

33. Twisted!
/orders
GET - List all orders
PUT
/customers/{id}/orders
POST - Add new order
DELETE
GET - Get all orders for customer
PUT
HTTP /orders/{id} POST - Add order
DELETE - Cancel all customer orders
GET GET - Get order details
PUT PUT - Update order
POST POST - Add item /customers/{id}
DELETE DELETE - Cancel order
GET - Get customer detail
PUT - Update customer
/customers POST
DELETE - Delete customer
GET - List all customers
PUT - Update customer
POST
DELETE - Delete customer
[Example taken from http://www.infoq.com/articles/rest-introduction by Stefan Tilkov]

34. Statelessness
• No conversational state: every request
carries all the information needed to its
fulfillment
• Implies that every possible server state is
exposed as a resource

35. HATEOAS (!)
• Addressability enables clients to follow
links to “next states”
• http://www.google.fr/search?q=Fabio
+Mancinelli&start=2

36. Prior art
A sense of déjà vu?

37. Unix
(Almost) Everything is a file

38. Unix
(Almost) Everything is a file
Uniform interface
+ read()
+ write()

39. Pipes
for i in $(seq 13830 21829); do
egrep "^From:" $i | awk '{print $2 $3}';
done
| sort | uniq -c | sort -nr | head -n15
[Extract the Top-15 most active people on the eclipse.newcomer newsgroup during the last year
http://eclipsewebmaster.blogspot.com/2008/02/newcomer-newsgroups-top-15.html]

40. /dev and /proc
/dev /proc
|-- hda |-- cpuinfo
|-- hda1 |-- kcore
|-- cdrom |-- modules
|-- audio |-- pci
|-- ... |-- ...

41. /dev and /proc
• Make/dev/hda >image of the whole disk:
cat
a backup
backup.img
• Play music.mp3 > /dev/audio
cat
music:
• Record voice: > mytalk.wav
cat /dev/audio
• Change system settings:
echo “0” > /proc/sys/net/ipv4/ip_forward

42. Pervasively RESTful
Bringing REST everywhere

43. A “Pervasive Web”
• From objects providing services to
resources representing things (...and their
state)
• Applying REST principles to the pervasive
world
• Make pervasive contexts be part of “The
Web” and not running on top of it.

44. The vision
Expose the “pervasive hardware” RESTfully

45. The vision
GET ptp://room/light
PTP/1.0 200 OK
Content-type: text/xml
<state>
off
</state>

46. The vision
PUT ptp://room/light
Content-type: text/xml
<state>
on
</state>
PTP/1.0 200 OK

47. Challenges
• KISS: Keep It Sweet & Simple!
• New architectures and protocols
(extensions) for being pervasively RESTful:
Is “The Web” enough?
• Reconcile pervasive world’s peculiar
characteristics with a RESTful setting
• Overcoming REST limitations

48. Conclusions
• No conclusions yet... That’s the beginning!

49. Questions?
• WDYT? Does it make sense?