on being restful

49
On being RESTful Fabio Mancinelli fm@fabiomancinelli

Upload: fabio-mancinelli

Post on 11-May-2015

2.138 views

Category:

Documents


2 download

TRANSCRIPT

Page 1: On being RESTful

On being RESTfulFabio Mancinelli

fm@fabiomancinelli

Page 2: On being RESTful

An introduction to the REST architectural style...

A different way of looking atService Oriented Computing

What is this talk about?

Page 3: On being RESTful

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! ☺

Page 4: On being RESTful

A RESTless worldAlso known as “Service Oriented

Architecture”

Page 5: On being RESTful

Classic SOA

• Web-services

• WSDL

• SOAP

• UDDI Service provider

Servicerequester

Servicebroker

Register Search

Request

Page 6: On being RESTful

Classic SOA

• Web-services

• WSDL

• SOAP

• UDDI Service provider

Servicerequester

Servicebroker

Register Search

Request

WSDL WSDL

SOAP

Web Service

UDDI

Page 7: On being RESTful

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]

Page 8: On being RESTful

WSDL

XML description of the service interface

Page 9: On being RESTful

SOAP

• Was “Simple Object Access Protocol”, sometimes referred as SOA-Protocol

• Simply an XML-based messaging protocol used mainly as an RPC protocol

Page 10: On being RESTful

UDDI

• Universal Description, Discovery and Integration

• Platform-independent, XML-based registry for business services

• Accessible via SOAP, provides WSDLs (... and other complementary information)

Page 11: On being RESTful

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

Page 12: On being RESTful

The RESTful sideAlso known as “The Web”

Page 13: On being RESTful

1989

Page 14: On being RESTful

2008

Page 15: On being RESTful

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},}

Page 16: On being RESTful

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]

Page 17: On being RESTful

What is REST?

Page 18: On being RESTful

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

Page 19: On being RESTful

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

Page 20: On being RESTful

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

Page 21: On being RESTful

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

Page 22: On being RESTful

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

Page 23: On being RESTful

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

Page 24: On being RESTful

Web ConnectorsREST connector Web instantiation

Client libwww, libwww-perl

Server libwww, Apache API

Cache Browser cache, Akamai

Resolver Bind (DNS)

Tunnel SOCKS, SSL

Page 25: On being RESTful

Web Components

REST component Web instantiation

Origin server Apache httpd, Microsoft IIS

User agent Firefox, IE, Safari, ...

Gateway Squid, CGI, ...

Proxy CERN proxy, Gauntlet

Page 26: On being RESTful

A twisted perspectiveFrom interfaces to resources

Page 27: On being RESTful

REST Key principles

• Addressability

• Uniform interface

• Stateless communication

• Hypermedia As The Engine Of Application State

Page 28: On being RESTful

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...)

Page 29: On being RESTful

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

Page 30: On being RESTful

Uniform interface

API1

API3

API2

APIn

Page 31: On being RESTful

Uniform interface

Uniform interface

Page 32: On being RESTful

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]

Page 33: On being RESTful

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

Page 34: On being RESTful

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

Page 35: On being RESTful

HATEOAS (!)

• Addressability enables clients to follow links to “next states”

• http://www.google.fr/search?q=Fabio+Mancinelli&start=2

Page 36: On being RESTful

Prior artA sense of déjà vu?

Page 37: On being RESTful

Unix

(Almost) Everything is a file

Page 38: On being RESTful

Unix

(Almost) Everything is a file

Uniform interface

+ read()+ write()

Page 39: On being RESTful

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]

Page 40: On being RESTful

/dev and /proc

/dev |-- hda |-- hda1 |-- cdrom |-- audio |-- ...

/proc |-- cpuinfo |-- kcore |-- modules |-- pci |-- ...

Page 41: On being RESTful

/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

Page 42: On being RESTful

Pervasively RESTfulBringing REST everywhere

Page 43: On being RESTful

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.

Page 44: On being RESTful

The vision

Expose the “pervasive hardware” RESTfully

Page 45: On being RESTful

The visionGET ptp://room/light

PTP/1.0 200 OKContent-type: text/xml<state> off</state>

Page 46: On being RESTful

The visionPUT ptp://room/lightContent-type: text/xml<state> on</state>

PTP/1.0 200 OK

Page 47: On being RESTful

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

Page 48: On being RESTful

Conclusions

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

Page 49: On being RESTful

Questions?

• WDYT? Does it make sense?