24
REST in theory by / Alex Muntada @alexmuntada

REST in theory

Embed Size (px)

DESCRIPTION

My talk about REST in Barcelona Software Craftsmanship Meetup on May 19, 2014. http://www.meetup.com/Barcelona-Software-Craftsmanship/events/173793192/

Citation preview

Page 1: REST in theory

RESTin theory

by / Alex Muntada @alexmuntada

Page 2: REST in theory

What makes Internet a success?

World Wide Web

Page 3: REST in theory

What makes the Web a success?easycustomizedlinkedpervasive

Page 4: REST in theory

Timeline

Page 5: REST in theory

Architectural Styles and theDesign of Network-based

Software ArchitecturesRoy Fielding (2000)

Page 6: REST in theory

SOAP 1.2W3C recommendation (2003)

Page 7: REST in theory

RESTful Web ServicesLeonard Richardson, Sam Ruby (2007)

Page 9: REST in theory

RESTful Web APIsLeonard Richardson, Mike Amundsen, Sam Ruby (2013)

Page 10: REST in theory

REST(ful)“Representational state transfer (REST) is a softwarearchitectural style consisting of a coordinated set ofarchitectural constraints applied to components,connectors, and data elements, within a distributed

hypermedia system.”

Page 11: REST in theory

Architectural Properties of the WebLow Entry-Barrier (easy)Extensibility (customized)Distributed Hypermedia (linked)Internet-Scale (pervasive)

Page 12: REST in theory

Interface ConstraintsIdentification of Resources (URIs)Manipulation of Resources Through RepresentationsSelf-Descriptive Messages (stateless)The Hypermedia Constraint (HATEOAS)

Page 13: REST in theory

HATEOAS“Hypermedia as the engine of application state.”

All application state is kept on the client side.The client can only change it through HTTP requests and responses.The client can find next actions through hypermedia controls.Hypermedia controls drive changes in application state.

Page 14: REST in theory

Architectural ConstraintsClient-Server (one to one)Statelessness (application state, resource state)Caching (if-modified-since, if-match, 304)

Layered System (proxies, gateways)Code on Demand (javascript)

Uniform Interface

Page 16: REST in theory

What is your worst nightmare in APIs?

DocumentationBad, old, wrong or lack thereof.

Page 17: REST in theory

Twitter REST API v1.1POST statuses/update

Resource URL: https://api.twitter.com/1.1/statuses/update.jsonHTTP Methods: POSTResponse Formats: jsonParameters: status (required), in_reply_to_status_id, lat, long, place_id,display_coordinates, trim_user

Page 18: REST in theory

What is missing in this example?POST /1.1/statuses/update.json HTTP/1.1User-Agent: curl/7.35.0Host: api.twitter.comAccept: */*Content-Length: 68Content-Type: application/x-www-form-urlencoded

status=Maybe%20he%27ll%20finally%20find%20his%20keys.%20%23peterfalk

HTTP/1.1 400 Bad Requestcontent-length: 61content-type: application/json; charset=utf-8date: Sun, 18 May 2014 19:30:43 UTCserver: tfeset-cookie: guest_id=v1%3A140044144371735781; Domain=.twitter.com; Path=/; Expires=Tue, 17-May-2016 19:30:43 UTCstrict-transport-security: max-age=631138519x-tfe-logging-request-category: API

{"errors":[{"message":"Bad Authentication data","code":215}]}

Page 19: REST in theory

How can I fix it?POST /1.1/statuses/update.json HTTP/1.1User-Agent: curl/7.35.0Host: api.twitter.comAccept: */*Content-Length: 68Content-Type: application/x-www-form-urlencodedAuthorization: OAuth oauth_consumer_key="xvz1evFS4wEEPTGEFPHBog", oauth_nonce="kYjzVBB8Y0ZFabxSWbWovY3uYSQ2pTgmZeNu2VS4cg", oauth_signature="tnnArxj06cWHq44gCs1OSKk%2FjLY%3D", oauth_signature_method="HMAC-SHA1", oauth_timestamp="1318622958", oauth_token="370773112-GmHxMAgYyLbNEtIKZeRNFsMKPR9EyMZeS9weJAEb", oauth_version="1.0"

status=Maybe%20he%27ll%20finally%20find%20his%20keys.%20%23peterfalk

Page 20: REST in theory

How did I find that?Read several pages of documentation:1. 2. 3. 4.

POST statuses/updateApplication-user authenticationUsing OAuthAuthorizing a request

Page 21: REST in theory

The Semantic Gap“The gap between the structure of a document and its

real-world meaning—its application semantics.Media types, machine-readable profiles, and human-readable documentation bridge the semantic gap indifferent ways, but bridging the gap always requiresthe intervention of a human being at some point.”

RESTful Web APIs, p. 360

Page 22: REST in theory

Final ThoughtsTry to use less documentation and more hypermedia.Use existing standards, content types, link relations, etc.Propose new ones when there are none.Think about Internet-scale APIs.Let your APIs socialize with other APIs.Embrace the semantic challenge!

Page 23: REST in theory

Questions?by Alex Muntada / @alexmuntada

Page 24: REST in theory

REST in peace!