on being restful
TRANSCRIPT
On being RESTfulFabio Mancinelli
fm@fabiomancinelli
An introduction to the REST architectural style...
A different way of looking atService Oriented Computing
What is this talk about?
An introduction to the REST architectural style...
A different way of looking atService Oriented Computing
What is this talk about?
...and some ideas to foster discussion forfinding new research directions! ☺
A RESTless worldAlso known as “Service Oriented
Architecture”
Classic SOA
• Web-services
• WSDL
• SOAP
• UDDI Service provider
Servicerequester
Servicebroker
Register Search
Request
Classic SOA
• Web-services
• WSDL
• SOAP
• UDDI Service provider
Servicerequester
Servicebroker
Register Search
Request
WSDL WSDL
SOAP
Web Service
UDDI
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]
WSDL
XML description of the service interface
SOAP
• Was “Simple Object Access Protocol”, sometimes referred as SOA-Protocol
• Simply an XML-based messaging protocol used mainly as an RPC protocol
UDDI
• Universal Description, Discovery and Integration
• Platform-independent, XML-based registry for business services
• Accessible via SOAP, provides WSDLs (... and other complementary information)
The WS-* hell• WS-Policy
• WS-PolicyAssertions
• WS-PolicyAttachment
• WS-SecurityPolicy
• WS-Discovery
• WS-Introspection
• WS-Metadata Exchange
• WS-Resource Framework
• WS-Eventing
• WS-Addressing
• WS-Enumeration
• WS-Transfer
• WS-I Basic Profile
• WS-I Basic Security Profile
• WS-BPEL
• WS-CDL
• WS-Security
• WS-Secure Conversation
• WS-Security Policy
• WS-Trust
• WS-Federation
• WS-Federation Active Requestor Profile
• WS-Federation Passive Requestor Profile
• WS-Reliable Messaging
• WS-Reliability
• WS-Atomic Transaction
• WS-Business Activity
• WS-Notification
• WS-Eventing
• WS-Management
• WS-Management Catalog
• WS-Resource Transfer
The RESTful sideAlso known as “The Web”
1989
2008
2000
@PHDThesis{REST, Author = {Roy Thomas Fielding}, Title = {Architectural styles and the design of network-based software architectures}, Year = {2000}, Publisher = {University of California, Irvine},}
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]
What is REST?
What is REST?
• Data elements• Resources and identifiers
• Representations
• Metadata
• Control data
• Connectors• Client
• Server
• Cache
• Resolver
• Tunnel
• Components• User agent
• Origin server
• Gateway
• Proxy
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
• RepresentationsA machine-understandable description of the current resource state; typically a sequence of bytes in a well defined format known as the media-type
• MetadataAdditional data used to provide additional information about a representation, that cannot be extrapolated from the representation itself
• Control dataInformation describing the purpose of a message exchanged between components
Connectors• Client connector
Initiates communication and performs requests
• Server connectorListens for connections and replies to requests
• Cache connectorAssociated to a client or server connector, saves replies to requests for a later usage
• ResolverTranslates resource identifiers to network addresses for the actual communication
• TunnelRelays communication across communication boundaries
Components
• User agentUses a client connector to perform requests and is the final recipient of responses
• Origin serverUses a server connector for processing requests and providing responses. It is the source of resource representations and is the entity governing their state
• ProxyAn intermediary entity selected by a client for performance enhancement, data translation, etc.
• GatewayAn intermediary entity imposed by the network or by the origin server with similar functions as a proxy
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
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
Web ConnectorsREST connector Web instantiation
Client libwww, libwww-perl
Server libwww, Apache API
Cache Browser cache, Akamai
Resolver Bind (DNS)
Tunnel SOCKS, SSL
Web Components
REST component Web instantiation
Origin server Apache httpd, Microsoft IIS
User agent Firefox, IE, Safari, ...
Gateway Squid, CGI, ...
Proxy CERN proxy, Gauntlet
A twisted perspectiveFrom interfaces to resources
REST Key principles
• Addressability
• Uniform interface
• Stateless communication
• Hypermedia As The Engine Of Application State
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...)
Uniform interface
• A single interface is used to access and manipulate resources
• Well defined semantics
• HTTP is the uniform interface to the webVerb (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
Uniform interface
API1
API3
API2
APIn
Uniform interface
Uniform interface
Twisted!
OrderManagementService
+ getOrders()+ submitOrder()+ getOrdersForCustomers()+ updateOrder()+ addOrderItem()+ cancelOrder() CustomerManagementService
+ getCustomers()+ addCustomer()+ getCustomerDetail()+ updateCustomer()+ deleteCustomer()
[Example taken from http://www.infoq.com/articles/rest-introduction by Stefan Tilkov]
Twisted!
[Example taken from http://www.infoq.com/articles/rest-introduction by Stefan Tilkov]
HTTP
GETPUTPOSTDELETE
/orders
GET - List all ordersPUT POST - Add new orderDELETE
/orders/{id}
GET - Get order detailsPUT - Update orderPOST - Add itemDELETE - Cancel order
/customers
GET - List all customersPUT - Update customerPOSTDELETE - Delete customer
/customers/{id}
GET - Get customer detailPUT - Update customerPOSTDELETE - Delete customer
/customers/{id}/orders
GET - Get all orders for customerPUTPOST - Add orderDELETE - Cancel all customer orders
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
HATEOAS (!)
• Addressability enables clients to follow links to “next states”
• http://www.google.fr/search?q=Fabio+Mancinelli&start=2
Prior artA sense of déjà vu?
Unix
(Almost) Everything is a file
Unix
(Almost) Everything is a file
Uniform interface
+ read()+ write()
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 yearhttp://eclipsewebmaster.blogspot.com/2008/02/newcomer-newsgroups-top-15.html]
/dev and /proc
/dev |-- hda |-- hda1 |-- cdrom |-- audio |-- ...
/proc |-- cpuinfo |-- kcore |-- modules |-- pci |-- ...
/dev and /proc
• Make a backup image of the whole disk:cat /dev/hda > backup.img
• Play music: cat music.mp3 > /dev/audio
• Record voice:cat /dev/audio > mytalk.wav
• Change system settings: echo “0” > /proc/sys/net/ipv4/ip_forward
Pervasively RESTfulBringing REST everywhere
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.
The vision
Expose the “pervasive hardware” RESTfully
The visionGET ptp://room/light
PTP/1.0 200 OKContent-type: text/xml<state> off</state>
The visionPUT ptp://room/lightContent-type: text/xml<state> on</state>
PTP/1.0 200 OK
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
Conclusions
• No conclusions yet... That’s the beginning!
Questions?
• WDYT? Does it make sense?