restful web apps - facts vs fiction

© Copyright 2008, Yahoo! Inc.

Subbu Allamaraju - RESTful Web Applications

Colorado Software Summit: October 19 – 24, 2008

RESTful Web Apps

Facts vs Fiction

Subbu Allamaraju Yahoo! Inc || http://subbu.org


Subbu Allamaraju – RESTful Web Apps


Slide 2

About   Tech Yahoo!

 Developing standards, patterns and practices for HTTP web APIs

  Past  Developer – web services and Java  Standards contributor at BEA  Wrote books on JEE web tier (so long ago)

  Current Passion  HTTP and REST




Disclaimer

3

All the opinions I express here are mine and do not necessarily represent those

of my present or past employers.




A Confession   Not a web developer   Not directly interested in the internals

of web frameworks   Only interested in the visible aspects of

web apps

4




Agenda

REST – The Architecture

5

About RESTfulness of Web Apps




Some History 1945 - Vannevar Bush

arbitrary linking between pieces of information 1965 – Ted Nelson (Xanadu fame)

hypertext and hypermedia 1990s – Tim Berners-Lee, Roy Fielding et. al. WWW, HTML, HTTP and URI

HTTP 1.1 - RFC 2616 URI - RFC 2396 (superceded by 3986)

2000 – Roy Fielding Representational State Transfer

6




Two Sides

7

REST

HTTP, URI, WWW

REST

Web frameworks

MVC

Web 2.0

+ REST URIs (?)

RPC

SOAP WS-*

Human Facing Machine Facing

This session

“Pragmatic REST”




WEB IS MOSTLY RESTFUL

8




Being RESTful Resources Named via URIs Uniquely identify resources Have representations Mostly one/resource Reflect the state of the app Contain contextual links Uniform interface Generic, Client-Server Idempotent, safe, cacheable …

9

HATEOAS




Resources and URIs   Resources and URIs

 A blog post, an image, a catalog, a shopping cart

10

  Some personalized, but most are not

  Some depend on sessions, but most do not




Cost of Personalized UI http://my.example.org

vs http://www.example.org/subbu

11




Representations   Rich of representations

 HTML, XML, JS, PDF, CSS, Flash, …

12

  Poor content negotiation   Agent-driven negotiation +

Poor negotiation headers   Media types on responses

ignored sometimes   Constrained by HTML <a href=“mydoc.pdf”>Click</a> <a href=“myfeed.rss”>RSS Feed</a> <a href=“myfeed.atom”>Atom Feed</a>




Hypermedia and HATEOAS   Rich Hypermedia

 Links and forms  Contextual

  Auto-discoverable  <link/>, microformats

13

  Except some new breed of Web Too Oh + REST goo




Uniform Interface   Links and Forms

 GET and POST

14

  Still some misconceptions (e.g. POST is secure)

  Idempotency? Safety?   GET URIs not always refreshable   Still fighting the back button




Back Button Cache-Control: no-cache,no-store

15

Redirect after POST a.k.a. PRG (POST/redirect/GET)




Caching   Web is read-most   Cacheable   Widely discussed

16

  Yet moderately ignored   Cache busting   Cache-ignorant frameworks   Frameworks that prefer backend

caching over HTTP caching




Caching Choices   Back-end caching

 Non-uniform interface  Need to explicitly program to it

  HTTP caching  Uniform interface  Pluggable

17




Ajax Apps   More opportunities to be RESTful

 Full support for the uniform interface  Content negotiation, optimistic

concurrency, caching  HATEOAS

• Can loosen this constraint as long as the client code is downloaded from the same server/app

18




Cross-Domain Hacks   script, iframe   Tunnel requests over GET

19




Web is Mostly RESTful Take advantage of the web arch

20

Breaking is EXPENSIVE Breaking is CONFUSING Breaking LOWERS expectations




WEB FRAMEWORKS

21




State of Affairs

Ease of programming

Fragmentation and confusion

Innovation vs Correctness

22




Circa 1997-   There were servlets   Basic plumbing, closely reflecting HTTP

1.1   A poor programming model   But allowed a lot of frameworks to be

built on top

23




Circa 2001-

24

Action Oriented




Circa 2004-   Enter JSF & Co.

 A component based UI framework

  With known limitations  Complex  Slow  Uses POST for almost everything  And so on…

  Third-party patches

25




Design Choice

26




Where to keep this stuff?

27




We know. So what?

Consequence

28




URI Overloading

Client 1 Resource (URI)

Representation

Client 2 Resource (URI)

Different Representation How was this chosen?

29




URI Overloading   One URI – multiple representations

 No way to tell how a representation was chosen

 Can get wrong content from a cache

  HTTP does allow URI overloading  Content negotiation aka “conneg”

30




Content Negotiation

31

Accept: application/atom+xml;q=1.0,text/html;q=0.1 Accept-Charset: UTF-8 Accept-Language: fr;q=1.0,en=0.8 Accept-Encoding: gzip,deflate

Content-Type: application/atom+xml;charset=UTF-8 Content-Encoding: deflate Vary: Accept,Accept-Encoding




Some Options   Vary by cookie

 Not always recognized by caches  Complex given the parameters in a cookie

• Domain, path, life time etc

  URLEncode  Encode session ID into URIs

• ;jsessionid=d8sdasg7312

  Cache-control: no-cache,no-store

32




JSF Compromise

<context-param> <param-name> javax.faces.STATE_SAVING_METHOD </param-name> <param-value> client </param-value> </context-param>

33




Implementation

<form method="POST" action="…" enctype="…"> <input type="hidden" name="javax.faces.ViewState” value="H4s…zogsAAA==" />

… </form>

34

State stuffed into forms as a hidden field

Every request must be a POST




Consequence

Breaks the uniform interface

35




JSF vs REST   Caught between two extremes

 URIs no longer sufficient to identify a resource

 Interactions assume existence of session state – i.e. no longer stateless

 Uniform interface limited to POST  Interactions not idempotent  Representations not cacheable

36




JSF – Takeaway   Focused heavily on a UI component

model (AWT for the Web)   Misinterpreted the web architecture   Made some fundamental questionable

choices   You can patch, but can not fix

 15+ Ajax patches!

37




WEB 2.0 MOTIVATED

38




GWT   A cross-compilation based framework

 Write Java – generate JavaScript  Mashes up client and server code into

single source  These layers communicate using GWT-RPC

  Typical RPC concern does not apply  Coupling due to code generation  Client downloaded from the same app

39




GWT-RPC

Object result = someServ.doIt(new MyCallback()); public class MyCallback extends AsyncCallback() { public void onsuccess(Object result) { ... } }

40




GWT-RPC over HTTP

41




GWT-RPC over HTTP   Method calls POSTed to the server

 Transport object graphs  Uses HTTP like a transport layer

  Non uniform interface

42




GWT – Request Builder

String url = "..."; RequestBuilder builder = new RequestBuilder(RequestBuilder.GET, URL.encode(url)); builder.sendRequest(data, callback);

43




RequestBuilder over HTTP   More control over HTTP requests   Supports GET and POST   Allows so-called RESTful layers

 GWT-REST  GWT-Restlet

44




GWT Takeway   Focused heavily on ease of use

 Javascript agnostic

  Modeled after RPC  Breaks uniform interface  Backend caching over HTTP caching

  Fixable

45




Fixing GWT?

46

Object result = someServ.doGet(new MyCallback());

Object result = someServ.doPost(new MyCallback());

Object result = someServ.doPut(new MyCallback());

Object result = someServ.doDelete(new MyCallback());

Object result = someServ.doHead(new MyCallback());




SOFEA   Central premise – SOA

 Business logic as reusable services • Change less often

 Presentation app calling those services • Change more often

 Separation of concerns and Loose coupling

  Misinterprets HATEOAS

47




HATEOAS vs SOFEA

48

App download

App flow Data

interchange

Download server

Business logic server

App container




Appcelerator   A SOFEA style framework with RoR like

usability  Attend Matt Riable’s session on “Building

Rich Internet Applications with Appcelerator”

  SOAP/HTTP style  Message passing  POST to a single URI

49




XML over POST

50




Interesting … but   Loosens HATEOAS

 Hypermedia to Code + Data

  Introduces a different kind of coupling  Clients deal with POX and not links  Breaks URI opacity

  Examples  Appcelerator – SOAP like  http://www.applebox.com.au - uses SOAP/POST  http://www.contactoffice.com - uses XML/POST

51




Thanks   Don’t fight the architecture

 Innovate, enhance  Don’t break  Or break judiciously

52

restful web apps - facts vs fiction

Technology

colorado software summit

caching web

web archbreaking

web developer

rest session web

internals of web frameworks

jee web tier

rest uris