Copyright 2005 John Cowan under GPL   1


     RESTful Web Services

An introduction to building Web Services
without tear...
Copyright 2005 John Cowan under GPL   2


                 Copyright
●   Copyright © 2005 John Cowan
●   Licensed under th...
Copyright 2005 John Cowan under GPL   3


                  The Pitch

 Would you like something cleaner than SOAP?
    So...
Copyright 2005 John Cowan under GPL   4


                   The Pitch

 It’s all No Problem. It’s all Easy as Pi. REST is...
Copyright 2005 John Cowan under GPL   5


                   The Pitch

 By deconstructing what you already know about
the...
Copyright 2005 John Cowan under GPL   6


               Talk is cheap



But that's what you're going to get today. After...
Copyright 2005 John Cowan under GPL   7


       Uniform Resource Identifier
●   I use the term “URI” (Uniform Resource
  ...
Copyright 2005 John Cowan under GPL   8


                         Credits
●   The guts of this presentation comes from th...
Copyright 2005 John Cowan under GPL   9


                      Roadmap
•   Web Services (12)          •   From here to th...
Copyright 2005 John Cowan under GPL   10




Web Services
Copyright 2005 John Cowan under GPL   11


          What’s a Web Service?
●   A web service is just a web page meant for ...
Copyright 2005 John Cowan under GPL   12


           What’s a Web Service?
●   Web Services require an architectural styl...
Copyright 2005 John Cowan under GPL   13


         The scope of the problem
●   Computer A in New York ...
●   ... tells ...
Copyright 2005 John Cowan under GPL   14


                       Nouns
●   URIs are the equivalent of a noun
●   Most wor...
Copyright 2005 John Cowan under GPL   15


                      Verbs
●   Verbs (loosely) describe actions that are
    a...
Copyright 2005 John Cowan under GPL   16


          GET: fetch information
●   To fetch a web page, the browser does a GE...
Copyright 2005 John Cowan under GPL   17


        Four verbs for every noun
●   GET to retrieve information
●    POST to ...
Copyright 2005 John Cowan under GPL   18


             Not such a big deal
●   The Web already supports machine-to-
    m...
Copyright 2005 John Cowan under GPL   19


                       XML
●   Using XML formats as your machine-
    processab...
Copyright 2005 John Cowan under GPL   20


        Why not just use plain HTML?
●   Web pages are designed to be understoo...
Copyright 2005 John Cowan under GPL   21


        Well, not quite every URI
●   The information on some pages is going to...
Copyright 2005 John Cowan under GPL   22


          Are we doing this now?
●   Most of us are are busy writing to layers ...
Copyright 2005 John Cowan under GPL   23




What’s REST?
Copyright 2005 John Cowan under GPL   24


         So what's REST already?
●   REpresentational State Transfer
●   An arc...
Copyright 2005 John Cowan under GPL   25


                 REST defined
●   Resources are identified by uniform resource
...
Copyright 2005 John Cowan under GPL   26


                    REST style
●   Client-server
●   Stateless
●   Cached
●   U...
Copyright 2005 John Cowan under GPL   27


               Snarky question
●   How are representations transferred, and why...
Copyright 2005 John Cowan under GPL   28


                  Representation
●   Resources are first-class objects
    –   ...
Copyright 2005 John Cowan under GPL   29


         A web page is a resource?
●   A web page is a representation of a reso...
Copyright 2005 John Cowan under GPL   30


                        State
●   “State” means application/session state
●    ...
Copyright 2005 John Cowan under GPL   31


               Transfer of state
●   Connectors (client, server, cache, resolve...
Copyright 2005 John Cowan under GPL   32


               REST and HTTP
●   REST is a post hoc description of the Web
●   ...
Copyright 2005 John Cowan under GPL   33


                  Other protocols
●   Web interaction using other protocols is
...
Copyright 2005 John Cowan under GPL   34


             Existing HTTP uses
●   Web browsing (obviously)
●   Instant messag...
Copyright 2005 John Cowan under GPL   35


What do REST messages look like?
●   Like what we already know: HTTP, URIs, etc...
Copyright 2005 John Cowan under GPL   36


         Multiple representations
●   Most resources have only a single
    rep...
Copyright 2005 John Cowan under GPL   37


               Why hypertext?
●   Because the links mirror the structure of how...
Copyright 2005 John Cowan under GPL   38


            Web-based applications
●   A Web-based application is a dynamically...
Copyright 2005 John Cowan under GPL   39


                 Code on demand
●   Java applets weren’t so hot
●   Javascript ...
Copyright 2005 John Cowan under GPL   40


    A few simple tests of RESTfulness
●   Can I do a GET on the URLs that I POS...
Copyright 2005 John Cowan under GPL   41


    A few simple tests of RESTfulness
●   Would the client notice if the server...
Copyright 2005 John Cowan under GPL   42




The killer argument
Copyright 2005 John Cowan under GPL   43


    Arguments against non-REST designs
●   They break Web architecture, particu...
Copyright 2005 John Cowan under GPL   44


              Caching? Well ...
●   The Web's caching architecture of the Web
 ...
Copyright 2005 John Cowan under GPL   45


               Scaling? Well...
●   What kind of scaling is most important is
 ...
Copyright 2005 John Cowan under GPL   46


              The killer argument
●   A service offered in a REST style will
  ...
Copyright 2005 John Cowan under GPL   47


        What if REST is not enough?
●   What happens when you need application
...
Copyright 2005 John Cowan under GPL   48


                    But in fact:
●   There are no applications you can think of...
Copyright 2005 John Cowan under GPL   49


         Be fruitful and multiply
●   REST design appears to make web apps more...
Copyright 2005 John Cowan under GPL   50




Distributed Systems
Copyright 2005 John Cowan under GPL   51


            Distributed Systems
●   Components (origin servers, gateways,
    p...
Copyright 2005 John Cowan under GPL   52


                 Components
●   Communicate by transferring representations
   ...
Copyright 2005 John Cowan under GPL   53


              Some components
●   Origin servers: Apache, IIS
●   Gateways: Squ...
Copyright 2005 John Cowan under GPL   54


                   Connectors
●   Present an abstract interface for component
 ...
Copyright 2005 John Cowan under GPL   55


              Some connectors
●   Clients: browsers, feedreaders, libraries, ma...
Copyright 2005 John Cowan under GPL   56


            The connector view
●   Concentrates on the mechanics of the
    com...
Copyright 2005 John Cowan under GPL   57


             Resource modeling
●   The value of components and connectors is
  ...
Copyright 2005 John Cowan under GPL   58


             Resource modeling
●   Organize a distributed application into URI-...
Copyright 2005 John Cowan under GPL   59


             Some data elements
●   Resources: the intended conceptual target o...
Copyright 2005 John Cowan under GPL   60


              Advantages of REST
●   Its architectural constraints when applied...
Copyright 2005 John Cowan under GPL   61


            Advantages of REST
●   Supports intermediaries (proxies and
    gat...
Copyright 2005 John Cowan under GPL   62


            Advantages of REST
●   Separates server implementation from the
   ...
Copyright 2005 John Cowan under GPL   63


                  The key insights
●   Discrete resources should be given their...
Copyright 2005 John Cowan under GPL   64




What about ...
Copyright 2005 John Cowan under GPL   65


       GETs that won't fit in a URI
●    Restricting GET to a single line enfor...
Copyright 2005 John Cowan under GPL   66


                   Reliability
●   The Web consists of many redundant
    resou...
Copyright 2005 John Cowan under GPL   67


                   Reliability
●   You can do reliable delivery in HTTP easily ...
Copyright 2005 John Cowan under GPL   68


                    Reliability
●   If at first you don't succeed, try, try aga...
Copyright 2005 John Cowan under GPL   69


                      Reliability
●   Clients aren't that good at generating tr...
Copyright 2005 John Cowan under GPL   70


                      Reliability
●   The original POST is used only to generat...
Copyright 2005 John Cowan under GPL   71


                   Reliability
●   Wasted IDs are irrelevant.
●   Duplicated PO...
Copyright 2005 John Cowan under GPL   72


        Asynchronous operations
●   Send back notifications as POSTs (the clien...
Copyright 2005 John Cowan under GPL   73


                    Transactions
●   The client is ultimately responsible
●   O...
Copyright 2005 John Cowan under GPL   74


          REST outside the Web?
●   REST concepts apply in general to any syste...
Copyright 2005 John Cowan under GPL   75


                           B2B
●   B2B systems usually assume that POSTed
    d...
Copyright 2005 John Cowan under GPL   76


               Other protocols
●   Other protocols are not organized around URI...
Copyright 2005 John Cowan under GPL   77


               Tunneling HTTP
●   If you really do need non-HTTP transport,
   ...
Copyright 2005 John Cowan under GPL   78




Clarifying “state”
Copyright 2005 John Cowan under GPL   79


               Two kinds of state
●   Application state is the information nece...
Copyright 2005 John Cowan under GPL   80


                  Resource state
●   Changes in resource state are unavoidable
...
Copyright 2005 John Cowan under GPL   81


                  Session state
●   Session state is also application state
●  ...
Copyright 2005 John Cowan under GPL   82


                    Sessions
●   A purchasing client could send a single HTTP
 ...
Copyright 2005 John Cowan under GPL   83


        The purpose of statelessness
●   Prevents partial failures
●   Allows f...
Copyright 2005 John Cowan under GPL   84


           Another kind of state
●   Don’t confuse REST state with state-machin...
Copyright 2005 John Cowan under GPL   85




  From where we are
to where we’d like to be
Copyright 2005 John Cowan under GPL   86


     The “OOP on the Web” theory
●   HTTP is just a transport layer between obj...
Copyright 2005 John Cowan under GPL   87



         Smash the (private) state
●   Eliminating private state lets us devel...
Copyright 2005 John Cowan under GPL   88

           “My boss just wants it
         on time and under budget”
●   An anal...
Copyright 2005 John Cowan under GPL   89


             RPC characterized
●   Every object has its own unique methods
●   ...
Copyright 2005 John Cowan under GPL   90


      But in REST (just to rub it in)
●   Every useful data object has an addre...
Copyright 2005 John Cowan under GPL   91


                 REST and RPC
●   REST is, in a sense, a species of RPC, except...
Copyright 2005 John Cowan under GPL   92


             Remote procedures
●   Consider the stock example of a remote
    p...
Copyright 2005 John Cowan under GPL   93


         REST just RPC renamed?
●   But if we change the name from
    quot;get...
Copyright 2005 John Cowan under GPL   94


          There are no neutrals there
●   REST is incompatible with quot;end-po...
Copyright 2005 John Cowan under GPL   95


        Can REST really beat RPC?
●   If REST works and RPC doesn't, then yes!
...
Copyright 2005 John Cowan under GPL   96


             Two views of POST
●   “POST lets you pass a whole lot of parameter...
Copyright 2005 John Cowan under GPL   97


           REST: an alien notion
●   RPC-over-HTTP is well-matched with current...
Copyright 2005 John Cowan under GPL   98


           REST sounds ominous
●   Completely rethink your design in terms of
 ...
Copyright 2005 John Cowan under GPL   99


           REST sounds ominous
●   Plenty of people do know how to develop
    ...
Copyright 2005 John Cowan under GPL   100


              “REST is ha-ard”                --RPC Barbie

●   It sometimes t...
Copyright 2005 John Cowan under GPL   101


 Paul Prescod shows us the REST way
POST /purchase_orders HTTP/1.1
Host: accou...
Copyright 2005 John Cowan under GPL   102


   And then there’s the SOAP way
POST /generic_message_handler
content-type: a...
Copyright 2005 John Cowan under GPL   103


              Stacking the deck
●   Namespace declarations would make the SOAP...
Copyright 2005 John Cowan under GPL   104




SOAP
Copyright 2005 John Cowan under GPL   105


       SOAP: neither fish nor fowl
●   A base from which to build new protocol...
Copyright 2005 John Cowan under GPL   106


           SOAP can be RPC or not
●   Originally SOAP was a pure RPC transport...
Copyright 2005 John Cowan under GPL   107


         POSTing a SOAP message
●   Wrap the body in a SOAP envelope
●   POST ...
Copyright 2005 John Cowan under GPL   108


         POSTing a SOAP message
●   SOAP uses its envelope for what new HTTP
 ...
Copyright 2005 John Cowan under GPL   109


    The advantages of SOAPless GET
●    More tools out there that can do HTTP ...
Copyright 2005 John Cowan under GPL   110


    HTTP is not a transport protocol
●   If the body of a POST or PUT is not a...
Copyright 2005 John Cowan under GPL   111


    HTTP is not a transport protocol
●   SOAP abuses HTTP by treating it as a ...
Copyright 2005 John Cowan under GPL   112


        Web Method specification
●   SOAP 1.2 exposes the HTTP method through
...
Copyright 2005 John Cowan under GPL   113


        Web Method specification
●   Potentially radically different from the
...
Copyright 2005 John Cowan under GPL   114




Cleaning up current practice
Copyright 2005 John Cowan under GPL   115


                         Cookies
●   A receipt for application state handed ou...
Copyright 2005 John Cowan under GPL   116


            Cookies aren't all bad
●   At least there exists a reference to th...
Copyright 2005 John Cowan under GPL   117


                 Cookie problems
●   Cookies break visibility
    –   Caches d...
Copyright 2005 John Cowan under GPL   118


       Keeping state in the cookie
●   Lets URIs be independent of the user st...
Copyright 2005 John Cowan under GPL   119


        Keeping a reference to state
●   Storing state on the client provides ...
Copyright 2005 John Cowan under GPL   120


     Keeping identity in the cookie
●   Cookies are more efficient than proper...
Copyright 2005 John Cowan under GPL   121


                  Tunneling
●   Using POST to send data that's supposed to
   ...
Copyright 2005 John Cowan under GPL   122


      Don't tunnel through port 80
●   Firewalls and ports exist for a reason
...
Copyright 2005 John Cowan under GPL   123


      Don't tunnel through port 80
●   Security administrators will find a way...
Copyright 2005 John Cowan under GPL   124


    Application protocols and safety
●   Applications protocols provide safety...
Copyright 2005 John Cowan under GPL   125


    Application protocols and safety
●   SMTP doesn't include such tunneling f...
Copyright 2005 John Cowan under GPL   126


             Use HTTP as HTTP
●   Use HTTP because it is pragmatic
●   Also us...
Copyright 2005 John Cowan under GPL   127


      Plain HTTP vs. SOAP on HTTP
●   See Paul Prescod’s examples again
●   Wh...
Copyright 2005 John Cowan under GPL   128


    Working with REST, not against it
●   Reconsider your application's needs ...
Copyright 2005 John Cowan under GPL   129




RESTafarian Email: an example
Copyright 2005 John Cowan under GPL   130


             RESTafarian Email
●   If we were designing email from scratch on
...
Copyright 2005 John Cowan under GPL   131


    Mail servers keep outgoing mail
●   To post an email, use POST!
●   Your l...
Copyright 2005 John Cowan under GPL   132


    Mailbox servers keep inbox state
●   To read your mail, use GET to fetch a...
Copyright 2005 John Cowan under GPL   133


    Mailbox servers keep inbox state
●   Archived messages are displayed in vi...
Copyright 2005 John Cowan under GPL   134


               Mail notification
●   Mail servers have to tell mailbox servers...
Copyright 2005 John Cowan under GPL   135


                    No spam!
●   Any recipient can delete a message, so just
 ...
Copyright 2005 John Cowan under GPL   136


                   No spam!
●   Of course a spammer can cheat by using a
    s...
Copyright 2005 John Cowan under GPL   137


    “Post in haste, repent at leisure”
●   SMTP mail once sent can't be retrie...
Copyright 2005 John Cowan under GPL   138




Related architectures
Copyright 2005 John Cowan under GPL   139


Systems vs. applications programming
●   Systems programming emphasizes making...
Copyright 2005 John Cowan under GPL   140


       Thoughts of a systems geek
●   If applications programmers thought more...
Copyright 2005 John Cowan under GPL   141


                    The Unix Way
●   Unix has destroyed all its competitors bu...
Copyright 2005 John Cowan under GPL   142


                   The Unix Way
●   Everything is a file
    –   Files have a ...
Copyright 2005 John Cowan under GPL   143


      REST from a Unix viewpoint
●   Resources rather than files
●   URI space...
Copyright 2005 John Cowan under GPL   144


    Other coordination environments
●   In Linda, you get and put anonymous tu...
Copyright 2005 John Cowan under GPL   145




Final thoughts
Copyright 2005 John Cowan under GPL   146


             Has RPC really failed?
●   ONC and DCE RPC are the basis of:
    ...
Copyright 2005 John Cowan under GPL   147


                REST and WS-*
●   In the end, WS-* is just there, like Windows...
Copyright 2005 John Cowan under GPL   148


              You're my only hope
●   The only thing that can really make REST...
Upcoming SlideShare
Loading in …5
×

RESTful WebServices

5,344 views

Published on

Published in: Technology
0 Comments
14 Likes
Statistics
Notes
  • Be the first to comment

No Downloads
Views
Total views
5,344
On SlideShare
0
From Embeds
0
Number of Embeds
29
Actions
Shares
0
Downloads
512
Comments
0
Likes
14
Embeds 0
No embeds

No notes for slide

RESTful WebServices

  1. 1. Copyright 2005 John Cowan under GPL 1 RESTful Web Services An introduction to building Web Services without tears (i.e., without SOAP or WSDL) John Cowan cowan@ccil.org http://www.ccil.org/~cowan
  2. 2. Copyright 2005 John Cowan under GPL 2 Copyright ● Copyright © 2005 John Cowan ● Licensed under the GNU General Public License ● ABSOLUTELY NO WARRANTIES; USE AT YOUR OWN RISK ● Black and white for readability ● Gentium font for readability and beauty
  3. 3. Copyright 2005 John Cowan under GPL 3 The Pitch Would you like something cleaner than SOAP? Something less impenetrable than WSDL? Something less confusingly intertwingled than the various WS-* bafflegab standards? ... Say, just what is this Web Services jazz anyhow?
  4. 4. Copyright 2005 John Cowan under GPL 4 The Pitch It’s all No Problem. It’s all Easy as Pi. REST isn’t some obscure thing that nobody supports; it’s the way the Web already works, just formalized a bit and with some do’s and don’ts.
  5. 5. Copyright 2005 John Cowan under GPL 5 The Pitch By deconstructing what you already know about the Web, you can rebuild it into a set of principles for sound design, without worrying about it. No, it won’t be “you push the button, we do the REST”. But it’ll be clean, secure, straightforward, extensible, discoverable, maintainable.
  6. 6. Copyright 2005 John Cowan under GPL 6 Talk is cheap But that's what you're going to get today. After we're done here, go home and try it for yourself.
  7. 7. Copyright 2005 John Cowan under GPL 7 Uniform Resource Identifier ● I use the term “URI” (Uniform Resource Identifier) throughout ● If it makes you feel better, cross it out and use “URL” instead ● Contrary to all propaganda, there are no effective differences these days
  8. 8. Copyright 2005 John Cowan under GPL 8 Credits ● The guts of this presentation comes from the writings of: – Roy Fielding – Ryan Tomayko – Paul Prescod – Mark Baker – Jeff Bone (conversus) – All the contributors to RestWiki
  9. 9. Copyright 2005 John Cowan under GPL 9 Roadmap • Web Services (12) • From here to there (18) • What’s REST? (18) • SOAP (9) • The killer argument (7) • Cleaning up (14) • Distributed Systems (13) • RESTafarian email (8) • What about ... (13) • Related architectures (6) • Clarifying “state” (6) • Final thoughts (3)
  10. 10. Copyright 2005 John Cowan under GPL 10 Web Services
  11. 11. Copyright 2005 John Cowan under GPL 11 What’s a Web Service? ● A web service is just a web page meant for a computer to request and process ● More precisely, a Web service is a Web page that’s meant to be consumed by an autonomous program as opposed to a Web browser or similar UI tool
  12. 12. Copyright 2005 John Cowan under GPL 12 What’s a Web Service? ● Web Services require an architectural style to make sense of them, because there’s no smart human being on the client end to keep track ● The pre-Web techniques of computer interaction don't scale on the Internet ● They were designed for small scales and single trust domains
  13. 13. Copyright 2005 John Cowan under GPL 13 The scope of the problem ● Computer A in New York ... ● ... tells computer B in Samarkand ... ● ... about a resource available on Computer C in Timbuktu ● None of them belongs to the same trust domain
  14. 14. Copyright 2005 John Cowan under GPL 14 Nouns ● URIs are the equivalent of a noun ● Most words in English are nouns, from cat to antidisestablishmentarianism ● The REST language has trillions of nouns for all the concepts in all the heads and files of all the people in the world
  15. 15. Copyright 2005 John Cowan under GPL 15 Verbs ● Verbs (loosely) describe actions that are applicable to nouns ● Using different verbs for every noun would make widespread communication impossible ● In programming we call this “polymorphism” ● Some verbs only apply to a few nouns ● In REST we use universal verbs only
  16. 16. Copyright 2005 John Cowan under GPL 16 GET: fetch information ● To fetch a web page, the browser does a GET on some URI and retrieves a representation (HTML, plain text, JPEG, or whatever) of the resource identified by that URI ● GET is fundamental to browsers because mostly they just browse ● REST requires a few more verbs to allow taking actions
  17. 17. Copyright 2005 John Cowan under GPL 17 Four verbs for every noun ● GET to retrieve information ● POST to add new information, showing its relation to old information ● PUT to update information ● DELETE to discard information
  18. 18. Copyright 2005 John Cowan under GPL 18 Not such a big deal ● The Web already supports machine-to- machine integration ● What's not machine-processable about the current Web isn't the protocol, it's the content
  19. 19. Copyright 2005 John Cowan under GPL 19 XML ● Using XML formats as your machine- processable representations for resources allows applying new tools to old data ● It also simplifies interconnection with remote systems ● XML has plenty of tools, as we all know
  20. 20. Copyright 2005 John Cowan under GPL 20 Why not just use plain HTML? ● Web pages are designed to be understood by people, who care about layout and styling, not just raw data ● Every URI could have a human-readable and a machine-processable representation: – Web Services clients ask for the machine-readable one – Browsers ask for the human-readable one
  21. 21. Copyright 2005 John Cowan under GPL 21 Well, not quite every URI ● The information on some pages is going to be too complex for machines to understand ● Anna Karenina has lots of meaning, but making it into a non-trivial Web service is an AI- complete problem
  22. 22. Copyright 2005 John Cowan under GPL 22 Are we doing this now? ● Most of us are are busy writing to layers of complex specifications ● Our nouns aren't universal ● Our verbs aren't polymorphic ● The proven techniques of the Web are being discarded for a pot of messages
  23. 23. Copyright 2005 John Cowan under GPL 23 What’s REST?
  24. 24. Copyright 2005 John Cowan under GPL 24 So what's REST already? ● REpresentational State Transfer ● An architectural style, not a toolkit ● “We don't need no steenkin' toolkits!” ● A distillation of the way the Web already works
  25. 25. Copyright 2005 John Cowan under GPL 25 REST defined ● Resources are identified by uniform resource identifiers (URIs) ● Resources are manipulated through their representations ● Messages are self-descriptive and stateless ● Multiple representations are accepted or sent ● Hypertext is the engine of application state
  26. 26. Copyright 2005 John Cowan under GPL 26 REST style ● Client-server ● Stateless ● Cached ● Uniform interface ● Layered system ● (Code on demand)
  27. 27. Copyright 2005 John Cowan under GPL 27 Snarky question ● How are representations transferred, and why would I want a representation of something to be transferred to something else? ● Representations are all we really have (the shadows in Plato's cave) ● Representations are transferred by ordinary digital means – it's how we think about them that's new
  28. 28. Copyright 2005 John Cowan under GPL 28 Representation ● Resources are first-class objects – Indeed, “object” is a subtype of “resource” ● Resources are retrieved not as character strings or BLOBs but as complete representations
  29. 29. Copyright 2005 John Cowan under GPL 29 A web page is a resource? ● A web page is a representation of a resource ● Resources are just concepts ● URIs tell a client that there's a concept somewhere ● Clients can then request a specific representation of the concept from the representations the server makes available
  30. 30. Copyright 2005 John Cowan under GPL 30 State ● “State” means application/session state ● Maintained as part of the content transferred from client to server back to client ● Thus any server can potentially continue transaction from the point where it was left off ● State is never left in limbo
  31. 31. Copyright 2005 John Cowan under GPL 31 Transfer of state ● Connectors (client, server, cache, resolver, tunnel) are unrelated to sessions ● State is maintained by being transferred from clients to servers and back to clients
  32. 32. Copyright 2005 John Cowan under GPL 32 REST and HTTP ● REST is a post hoc description of the Web ● HTTP 1.1 was designed to conform to REST ● Its methods are defined well enough to get work done ● Unsurprisingly, HTTP is the most RESTful protocol ● But it's possible to apply REST concepts to other protocols and systems
  33. 33. Copyright 2005 John Cowan under GPL 33 Other protocols ● Web interaction using other protocols is restricted to REST semantics ● Sacrifices some of the advantages of other architectures – Stateful interaction with an FTP site – Relevance feedback with WAIS search ● Retains a single interface for everything
  34. 34. Copyright 2005 John Cowan under GPL 34 Existing HTTP uses ● Web browsing (obviously) ● Instant messaging ● Content management ● Blogging (with Atom) ● What's outside its scope?
  35. 35. Copyright 2005 John Cowan under GPL 35 What do REST messages look like? ● Like what we already know: HTTP, URIs, etc. ● REST can support any media type, but XML is expected to be the most popular transport for structured information. ● Unlike SOAP and XML-RPC, REST does not really require a new message format
  36. 36. Copyright 2005 John Cowan under GPL 36 Multiple representations ● Most resources have only a single representation ● XML makes it possible to have as many representations as you need ● You can even view them in a clever way, thanks to the magic of XSLT and CSS
  37. 37. Copyright 2005 John Cowan under GPL 37 Why hypertext? ● Because the links mirror the structure of how a user makes progress through an application ● The user is in control, thanks to the Back button and other non-local actions ● In a Web service, the client should be in control in the same sense
  38. 38. Copyright 2005 John Cowan under GPL 38 Web-based applications ● A Web-based application is a dynamically changing graph of – state representations (pages) – potential transitions (links) between states ● If it doesn’t work like that, it may be accessible from the Web, but it’s not really part of the Web
  39. 39. Copyright 2005 John Cowan under GPL 39 Code on demand ● Java applets weren’t so hot ● Javascript is very hot ● The XmlHttpRequest object lets you do REST from inside a web page – Most browsers provide it nowadays, with a few annoying differences – It doesn’t really require XML messages
  40. 40. Copyright 2005 John Cowan under GPL 40 A few simple tests of RESTfulness ● Can I do a GET on the URLs that I POST to? ● Iff so, do I get something that in some way represents the state of what I've been building up with the POSTs? ● HTML forms almost always fail miserably
  41. 41. Copyright 2005 John Cowan under GPL 41 A few simple tests of RESTfulness ● Would the client notice if the server were to be – restarted at any point between requests – re-initialized by the time the client made the next request ● These tests are not anything like complete
  42. 42. Copyright 2005 John Cowan under GPL 42 The killer argument
  43. 43. Copyright 2005 John Cowan under GPL 43 Arguments against non-REST designs ● They break Web architecture, particularly caching ● They don't scale well ● They have significantly higher coordination costs
  44. 44. Copyright 2005 John Cowan under GPL 44 Caching? Well ... ● The Web's caching architecture of the Web isn't always the Right Thing ● Using POST loosely to mean “don't cache” has been a good way of dealing with this problem ● Learning the stricter REST semantics of POST isn't just an extension of existing practice
  45. 45. Copyright 2005 John Cowan under GPL 45 Scaling? Well... ● What kind of scaling is most important is application-specific ● Not all apps are Hotmail, Google, or Amazon ● Integration between two corporate apps has different scaling and availability needs ● The right approach to one isn't necessarily the right approach to the other
  46. 46. Copyright 2005 John Cowan under GPL 46 The killer argument ● A service offered in a REST style will inherently be easier to consume than some complex API: – Lower learning curve for the consumer – Lower support overhead for the producer
  47. 47. Copyright 2005 John Cowan under GPL 47 What if REST is not enough? ● What happens when you need application semantics that don't fit into the GET / PUT / POST / DELETE generic interfaces and representational state model? ● People tend to assume that the REST answer is: – If the problem doesn't fit HTTP, build another protocol – Extend HTTP by adding new HTTP methods
  48. 48. Copyright 2005 John Cowan under GPL 48 But in fact: ● There are no applications you can think of which cannot be made to fit into the GET / PUT / POST / DELETE resources / representations model of the world! ● These interfaces are sufficiently general ● Other interfaces considered harmful because they increase the costs of consuming particular services
  49. 49. Copyright 2005 John Cowan under GPL 49 Be fruitful and multiply ● REST design appears to make web apps more likely to combine successfully with other web apps ● The resulting complexes of applications have a larger effect on the web as a whole ● REST tends to appear on the largest scales ● We don’t know in advance which apps will become large-scale
  50. 50. Copyright 2005 John Cowan under GPL 50 Distributed Systems
  51. 51. Copyright 2005 John Cowan under GPL 51 Distributed Systems ● Components (origin servers, gateways, proxies, user agents) ● Connectors (clients, servers, caches, resolvers, tunnels) ● Data elements (resources, resource identifiers, representations)
  52. 52. Copyright 2005 John Cowan under GPL 52 Components ● Communicate by transferring representations of resources through a standard interface rather than operating directly upon the resource itself ● Used to access, provide access to, or mediate access to resources ● Intermediaries are part of the architecture, not just infrastructure like IP routers
  53. 53. Copyright 2005 John Cowan under GPL 53 Some components ● Origin servers: Apache, IIS ● Gateways: Squid, CGI, Reverse Proxy ● Proxies: Gauntlet ● User agents: Firefox, Mozilla, Safari, IE
  54. 54. Copyright 2005 John Cowan under GPL 54 Connectors ● Present an abstract interface for component communication, hiding the implementation details of communication mechanisms ● All requests must be stateless, containing all the information necessary for the understanding of that request without depending on any previous request
  55. 55. Copyright 2005 John Cowan under GPL 55 Some connectors ● Clients: browsers, feedreaders, libraries, many specialized applications ● Servers: Apache, IIS, AOLserver ● Caches: browser cache, Akamai cache network ● Resolvers: DNS lookup, DOI lookup ● Tunnels: SOCKS, SSL after HTTP CONNECT
  56. 56. Copyright 2005 John Cowan under GPL 56 The connector view ● Concentrates on the mechanics of the communication between components. ● Constrains the definition of the generic resource interface
  57. 57. Copyright 2005 John Cowan under GPL 57 Resource modeling ● The value of components and connectors is mostly obvious ● Resources, representations, URIs, and standardized interfaces are more subtle matters
  58. 58. Copyright 2005 John Cowan under GPL 58 Resource modeling ● Organize a distributed application into URI- addressable resources ● Use only the standard HTTP messages -- GET, PUT, POST and DELETE -- to provide the full capabilities of that application
  59. 59. Copyright 2005 John Cowan under GPL 59 Some data elements ● Resources: the intended conceptual target of a hypertext reference ● Resource identifiers: URIs ● Resource metadata: source links, alternates ● Representations: HTML documents, JPEG images ● Representation-specific metadata: media type, last-modified time
  60. 60. Copyright 2005 John Cowan under GPL 60 Advantages of REST ● Its architectural constraints when applied as a whole, generate: – Scalable component interactions – General interfaces – Independently deployed connectors – Reduced interaction latency – Strengthened security – Safe encapsulation of legacy systems
  61. 61. Copyright 2005 John Cowan under GPL 61 Advantages of REST ● Supports intermediaries (proxies and gateways) as data transformation and caching components ● Concentrates the application state within the user agent components, where the surplus disk and cycles are
  62. 62. Copyright 2005 John Cowan under GPL 62 Advantages of REST ● Separates server implementation from the client's perception of resources (“Cool URIs Don’t Change”) ● Scales well to large numbers of clients ● Enables transfer of data in streams of unlimited size and type
  63. 63. Copyright 2005 John Cowan under GPL 63 The key insights ● Discrete resources should be given their own stable URIs ● HTTP, URIs, and the actual data resources acquired from URIs are sufficient to describe any complex transaction, including – session state – authentication/authorization
  64. 64. Copyright 2005 John Cowan under GPL 64 What about ...
  65. 65. Copyright 2005 John Cowan under GPL 65 GETs that won't fit in a URI ● Restricting GET to a single line enforces a good design principle that everything interesting on the web should be URI- addressable. ● Changing an application to fit GET's limitations makes the application better by making it compatible with the rest of the web architecture
  66. 66. Copyright 2005 John Cowan under GPL 66 Reliability ● The Web consists of many redundant resources ● It might be possible to find an alternate representation and transfer the session there ● Databases don’t normally allow this ● The Web is a world of constantly shifting, redundant, overlapping network components in a wide variety of states.
  67. 67. Copyright 2005 John Cowan under GPL 67 Reliability ● You can do reliable delivery in HTTP easily at the application level ● The guarantees provided by TCP get you pretty far, and then you need just a bit more ● Connector reliability is solved by redundancy and other standard means that have nothing to do with REST
  68. 68. Copyright 2005 John Cowan under GPL 68 Reliability ● If at first you don't succeed, try, try again! ● The HTTP GET, PUT and DELETE methods are already idempotent, but the POST method creates new resources ● Multiple POSTs of the same data must be made harmless ● Put some kind of message ID in a header or in the message body
  69. 69. Copyright 2005 John Cowan under GPL 69 Reliability ● Clients aren't that good at generating truly unique message IDs ● Paul Prescod’s solution: – The client POSTs to a URI asking for a unique server-generated message ID – The server returns an HTTP quot;Location:quot; header pointing to a newly generated URI where the client may POST the actual data.
  70. 70. Copyright 2005 John Cowan under GPL 70 Reliability ● The original POST is used only to generate message IDs, which are cheap. – Retire them (whether they have been used or not) after a few hours – Or hold on to them for weeks!
  71. 71. Copyright 2005 John Cowan under GPL 71 Reliability ● Wasted IDs are irrelevant. ● Duplicated POSTs are not acted on by the server ● The server must send back the same response the original POST got, in case the application is retrying because it lost the response
  72. 72. Copyright 2005 John Cowan under GPL 72 Asynchronous operations ● Send back notifications as POSTs (the client can implement a trivial HTTP server) ● Piggyback them on the responses to later requests ● No complete solution yet
  73. 73. Copyright 2005 John Cowan under GPL 73 Transactions ● The client is ultimately responsible ● Other designs aren't much better ● Database-style transactions don't scale well on the Web – Clients will start transactions and then forget about them – Ties up server resources – Locks out all other users
  74. 74. Copyright 2005 John Cowan under GPL 74 REST outside the Web? ● REST concepts apply in general to any system ● Some problems can be solved more cleanly or quickly with other non- or partially-REST approaches ● But then you can't really participate in the Web ● The larger or more foundational your system, the more you need REST
  75. 75. Copyright 2005 John Cowan under GPL 75 B2B ● B2B systems usually assume that POSTed documents disappear into each partner's internal business systems ● Business processes would actually work better if treated like a Web resource – An order is a resource – Shipments and payments are sub-resources ● Amazon gets this mostly right
  76. 76. Copyright 2005 John Cowan under GPL 76 Other protocols ● Other protocols are not organized around URIs the way HTTP is ● They break up the address space into pieces, some of which don't even have URIs ● HTTP was designed to manipulate resources labeled by URIs
  77. 77. Copyright 2005 John Cowan under GPL 77 Tunneling HTTP ● If you really do need non-HTTP transport, tunnel HTTP over that transport ● HTTP is pretty simple -- a couple of headers is all you absolutely need
  78. 78. Copyright 2005 John Cowan under GPL 78 Clarifying “state”
  79. 79. Copyright 2005 John Cowan under GPL 79 Two kinds of state ● Application state is the information necessary to understand the context of an interaction – Authorization and authentication information are examples of application state ● Resource state is the kind that the S in REST refers to ● The quot;statelessquot; constraint means that all messages must include all application state.
  80. 80. Copyright 2005 John Cowan under GPL 80 Resource state ● Changes in resource state are unavoidable – Someone has to POST new resources before others can GET them ● REST is about avoiding implicit or unnamed state; resource state is named by URIs ● Application state is required by the server to understand how to process a request
  81. 81. Copyright 2005 John Cowan under GPL 81 Session state ● Session state is also application state ● If you want a session, you often need smarter clients than a browser ● Specialized clients can manage both application and resource state
  82. 82. Copyright 2005 John Cowan under GPL 82 Sessions ● A purchasing client could send a single HTTP request mentioning everything it wanted to purchase in one message ● Shopping carts are for people, who have trouble keeping state in their heads
  83. 83. Copyright 2005 John Cowan under GPL 83 The purpose of statelessness ● Prevents partial failures ● Allows for substrate independence – Load-balancing – Service interruptions
  84. 84. Copyright 2005 John Cowan under GPL 84 Another kind of state ● Don’t confuse REST state with state-machine state ● REST state is the representation of the values of the properties of a resource ● State machines fit into REST when the states are expressed as resources with links indicating transitions
  85. 85. Copyright 2005 John Cowan under GPL 85 From where we are to where we’d like to be
  86. 86. Copyright 2005 John Cowan under GPL 86 The “OOP on the Web” theory ● HTTP is just a transport layer between objects ● Messages and objects are both opaque ● Objects jealously guard their private state
  87. 87. Copyright 2005 John Cowan under GPL 87 Smash the (private) state ● Eliminating private state lets us develop architectures that can scale to larger designs. ● REST systems transfer the entire state of the transaction at every state transition ● You can pick up where you left off by merely accessing the URI at a later time, regardless of client or server changes.
  88. 88. Copyright 2005 John Cowan under GPL 88 “My boss just wants it on time and under budget” ● An analogy: Our genes want everyone to reproduce ● But that doesn’t mean reproducing will always make you any happier ● If your want to build a web-accessible toolkit that a lot of people make use of, REST may help ● For a one-off project written by a small group of developers, REST may be irrelevant
  89. 89. Copyright 2005 John Cowan under GPL 89 RPC characterized ● Every object has its own unique methods ● Methods can be remotely invoked over the Internet ● A single URI represents the end-point, and that's the only contact with the Web ● Data hidden behind method calls and parameters ● Data is unavailable to Web applications
  90. 90. Copyright 2005 John Cowan under GPL 90 But in REST (just to rub it in) ● Every useful data object has an address ● Resources themselves are the targets for method calls ● The list of methods is fixed for all resources
  91. 91. Copyright 2005 John Cowan under GPL 91 REST and RPC ● REST is, in a sense, a species of RPC, except the methods have been defined in advance ● Most RPC applications don't adhere to the REST philosophy ● It’s possible to work with RPC-style tools to produce REST results ● Not that people actually do so!
  92. 92. Copyright 2005 John Cowan under GPL 92 Remote procedures ● Consider the stock example of a remote procedure called “getStockPrice” ● This isn't a resource (verb, not noun) ● It's not clear what what it means to GET, PUT, and POST to something called quot;getStockPricequot;
  93. 93. Copyright 2005 John Cowan under GPL 93 REST just RPC renamed? ● But if we change the name from quot;getStockPricequot; to quot;CurrentStockPricequot; (a noun), all is well! ☺ ● The differences between RPC and REST can be quite subtle ● If that were all, REST would be just a design style, not an architecture
  94. 94. Copyright 2005 John Cowan under GPL 94 There are no neutrals there ● REST is incompatible with quot;end-pointquot; RPC ● Either you address data objects or you address quot;software components“ – REST does the former – End-point RPC does the latter ● You can try to contort RPC protocols into working on data object URIs, but then you end up re-inventing a non-standard variant of HTTP
  95. 95. Copyright 2005 John Cowan under GPL 95 Can REST really beat RPC? ● If REST works and RPC doesn't, then yes! ● SOAP began as pure RPC and has been moving further and further away ● SOAP (and its parent XML-RPC) have been around for years and yet there is no killer app ● REST can point to the Web itself as proof that It Just Works
  96. 96. Copyright 2005 John Cowan under GPL 96 Two views of POST ● “POST lets you pass a whole lot of parameters and get something back, bypassing caches.” ● “POST lets you create new resources that are related to old ones.” ● The second is the REST attitude
  97. 97. Copyright 2005 John Cowan under GPL 97 REST: an alien notion ● RPC-over-HTTP is well-matched with current thinking ● Take an existing object model, and a little Web-specific glue, and simply export those interfaces to the Web ● The problems creep in down the road
  98. 98. Copyright 2005 John Cowan under GPL 98 REST sounds ominous ● Completely rethink your design in terms of generic interfaces ● Build servlet-style implementations of each resource ● Unpack and repack Request and Response objects ● The gluuuuue is up to yooooou.
  99. 99. Copyright 2005 John Cowan under GPL 99 REST sounds ominous ● Plenty of people do know how to develop servlets ● Still, most developers and data modellers think only in UML and OOP ● REST is potentially as significant a change as the transition from procedures to objects
  100. 100. Copyright 2005 John Cowan under GPL 100 “REST is ha-ard” --RPC Barbie ● It sometimes takes as much work to learn to use one tool well than five tools badly ● In the long run you are better off ● XML was ha-ard too for people used to HTML, flat files, and CSV ● “Some people refused to learn to use the telephone. They don’t work here any more.”
  101. 101. Copyright 2005 John Cowan under GPL 101 Paul Prescod shows us the REST way POST /purchase_orders HTTP/1.1 Host: accounting.mycompany.com content-type: application/purchase-order+xml .... <po>...</po>
  102. 102. Copyright 2005 John Cowan under GPL 102 And then there’s the SOAP way POST /generic_message_handler content-type: application/SOAP+XML <soap:envelope> <soap:body> <submit-purchase-order> <destination>accounting.mycompany.com</destination> <po>...</po> </submit-purchase-order> </soap:body> <soap:envelope>
  103. 103. Copyright 2005 John Cowan under GPL 103 Stacking the deck ● Namespace declarations would make the SOAP example much bigger ● XML is not magic pixie dust: sometimes plain text is all you need ● In the gazillions-of-transactions-per-second world, these things count ● Do more with less
  104. 104. Copyright 2005 John Cowan under GPL 104 SOAP
  105. 105. Copyright 2005 John Cowan under GPL 105 SOAP: neither fish nor fowl ● A base from which to build new protocols and tunnel them over existing application protocols (typically HTTP) ● A means to extend the semantics of those same application protocols
  106. 106. Copyright 2005 John Cowan under GPL 106 SOAP can be RPC or not ● Originally SOAP was a pure RPC transport like its ancestor XML-RPC ● More recent versions of SOAP promote the less problematic “document/literal” style, which is analogous to email: – No explicit method name – The recipient decides what to do
  107. 107. Copyright 2005 John Cowan under GPL 107 POSTing a SOAP message ● Wrap the body in a SOAP envelope ● POST it to an endpoint URI ● A response comes back, which you must unwrap ● Or you might get a fault, which overrides (older SOAP) or duplicates (newer SOAP) the HTTP response code
  108. 108. Copyright 2005 John Cowan under GPL 108 POSTing a SOAP message ● SOAP uses its envelope for what new HTTP headers could do ● SOAP provides the meta-metadata quot;actorquot; and quot;mustUnderstandquot; ● If the body of the SOAP message represents an entity that is being POSTed to something, at least part of the REST style is preserved
  109. 109. Copyright 2005 John Cowan under GPL 109 The advantages of SOAPless GET ● More tools out there that can do HTTP gets (proxies, spiders, browsers) than can interpret your SOAP method as a getter ● Resources that are gettable have URIs that can be linked to ● SOAP endpoints should at least provide an alternate interface that allows vanilla HTTP getting
  110. 110. Copyright 2005 John Cowan under GPL 110 HTTP is not a transport protocol ● If the body of a POST or PUT is not a piece of representational state, you're not doing REST ● HTTP already defines these methods and doesn't need new ones inside the POST body
  111. 111. Copyright 2005 John Cowan under GPL 111 HTTP is not a transport protocol ● SOAP abuses HTTP by treating it as a transport protocol like TCP – “HTTP only exists to carry bits, namely SOAP messages, with or without a method name” ● HTTP is an application protocol; it doesn't send bits, it transfers representational state
  112. 112. Copyright 2005 John Cowan under GPL 112 Web Method specification ● SOAP 1.2 exposes the HTTP method through the SOAP binding ● SOAP clients can use GET to retrieve SOAP envelopes that contain the state of the resource identified by the URI
  113. 113. Copyright 2005 John Cowan under GPL 113 Web Method specification ● Potentially radically different from the common uses of SOAP 1.1 ● Will SOAP 1.2 applications automatically become more RESTful? Not a bit ● Most SOAP users will probably continue to use SOAP 1.2 in the same ways as SOAP 1.1.
  114. 114. Copyright 2005 John Cowan under GPL 114 Cleaning up current practice
  115. 115. Copyright 2005 John Cowan under GPL 115 Cookies ● A receipt for application state handed out by the server ● Using cookies is being stateful: – Not all application state is carried in the message – The cookie's referent is held on the server
  116. 116. Copyright 2005 John Cowan under GPL 116 Cookies aren't all bad ● At least there exists a reference to the state ● The request can be load balanced to some other server within the same trust domain for processing ● Beyond that trust domain, cookies don't mean anything to anybody ● That makes people paranoid about them
  117. 117. Copyright 2005 John Cowan under GPL 117 Cookie problems ● Cookies break visibility – Caches don't understand them ● Cookies are bad authenticators – They give up security for efficiency ● Clients often shut off cookies to provide real or imagined privacy
  118. 118. Copyright 2005 John Cowan under GPL 118 Keeping state in the cookie ● Lets URIs be independent of the user state ● But it destroys the client's understanding of state as presented by hypertext ● It breaks the Back button
  119. 119. Copyright 2005 John Cowan under GPL 119 Keeping a reference to state ● Storing state on the client provides REST's scalability. ● Sites with client sessions on the back end are usually several orders of magnitude less scalable than REST-based applications ● They also require much more complex back- end engines (J2EE, for example)
  120. 120. Copyright 2005 John Cowan under GPL 120 Keeping identity in the cookie ● Cookies are more efficient than proper HTTP authentication – servers and intermediaries simply ignore them for most URIs (e.g., inline images) ● But the server is relying on security by obscurity ● Cross-site scripting and cookie guessing are real dangers
  121. 121. Copyright 2005 John Cowan under GPL 121 Tunneling ● Using POST to send data that's supposed to mean something other than POST to the recipient is tunneling ● Administrators detest tunneling and for good reason ● Because SOAP is a meta-application protocol, tunneling is its middle name
  122. 122. Copyright 2005 John Cowan under GPL 122 Don't tunnel through port 80 ● Firewalls and ports exist for a reason ● When you show up at the airport, if you claim that you are a pilot you'll probably get waved through more quickly. But ... ● It's dangerous to lie to the firewall systems put up by people working for the same company you do, trying to protect it from the outside world
  123. 123. Copyright 2005 John Cowan under GPL 123 Don't tunnel through port 80 ● Security administrators will find a way to shut your RPC over port 80 down ● Then you'll have to add another layer of obfuscation ● In the long run the extra layer will no longer buy you a free pass through the firewall ● You end up with an arms race of escalating obfuscation and detection
  124. 124. Copyright 2005 John Cowan under GPL 124 Application protocols and safety ● Applications protocols provide safety guarantees by providing a fixed interface ● Only limited things can be done through the interface ● SMTP doesn't let you do anything but send mail ● It can't be used to retrieve files unless somebody explicitly installs software that allows such tunneling
  125. 125. Copyright 2005 John Cowan under GPL 125 Application protocols and safety ● SMTP doesn't include such tunneling features by default ● Consequently it is trusted and well deployed ● (Spam is not an SMTP problem per se) ● Fixed interfaces are secure, because software implementing them only does what it's designed to do
  126. 126. Copyright 2005 John Cowan under GPL 126 Use HTTP as HTTP ● Use HTTP because it is pragmatic ● Also use HTTP as HTTP so that it works with, not against the firewall software and firewall administrators ● Make each message as visible as possible to the firewall, and invisible and opaque to crackers ● Letting arbitrary requests tunnel through your firewall is asking to lose
  127. 127. Copyright 2005 John Cowan under GPL 127 Plain HTTP vs. SOAP on HTTP ● See Paul Prescod’s examples again ● Which one can be readily filtered with security software? ● Which one can a sysadmin inspect and understand in a logfile?
  128. 128. Copyright 2005 John Cowan under GPL 128 Working with REST, not against it ● Reconsider your application's needs in terms of the provided interfaces and semantics ● Don't try to figure out how to subvert or extend HTTP to encompass what you think your application semantics are
  129. 129. Copyright 2005 John Cowan under GPL 129 RESTafarian Email: an example
  130. 130. Copyright 2005 John Cowan under GPL 130 RESTafarian Email ● If we were designing email from scratch on REST principles, what might it look like? ● This is one possible way, not the One True REST Way ● REST is nothing if not flexible, provided you stick to the few principles we've already seen
  131. 131. Copyright 2005 John Cowan under GPL 131 Mail servers keep outgoing mail ● To post an email, use POST! ● Your local outbound mail server exposes a URI where outbound messages can be posted ● Security makes sure only authorized users can post ● The mail never leaves the server until the sender or the recipient decide to delete it
  132. 132. Copyright 2005 John Cowan under GPL 132 Mailbox servers keep inbox state ● To read your mail, use GET to fetch a set of hyperlinks (nicely formatted) that represent incoming messages ● GETting one link sends you to the mail server that has the message and retrieves it ● DELETE removes messages you no longer want
  133. 133. Copyright 2005 John Cowan under GPL 133 Mailbox servers keep inbox state ● Archived messages are displayed in views you can GET ● Folderizing is POSTing a message containing a URI to the folder (which itself has a URI) ● Forwarding is almost like folderizing, but to someone else’s inbox ● Higher-level services like searches are done by POST and create new resources that you can wait for or GET later
  134. 134. Copyright 2005 John Cowan under GPL 134 Mail notification ● Mail servers have to tell mailbox servers that mail is available ● Inbound servers expose a URI that can be POSTed to with a cheap message containing just a URI
  135. 135. Copyright 2005 John Cowan under GPL 135 No spam! ● Any recipient can delete a message, so just keeping one copy on the spammer’s mail server won’t work ● Spammers would have to keep zillions of copies on their mail servers ● That costs $$$$ and draws attention ● A spam no one gets to read isn't a spam
  136. 136. Copyright 2005 John Cowan under GPL 136 No spam! ● Of course a spammer can cheat by using a server that improperly ignores DELETEs ● But that only works once, as such servers get blacklisted (and they cannot trivially hide their identities) ● No social problem can be completely solved by technical fixes
  137. 137. Copyright 2005 John Cowan under GPL 137 “Post in haste, repent at leisure” ● SMTP mail once sent can't be retrieved ● Senders can use PUT or DELETE to modify or remove their mails even after posting them ● Of course, that doesn't change the state in the recipient's head
  138. 138. Copyright 2005 John Cowan under GPL 138 Related architectures
  139. 139. Copyright 2005 John Cowan under GPL 139 Systems vs. applications programming ● Systems programming emphasizes making the new domain fit into the existing generic interfaces ● Applications programming models the application domain precisely first, worries about integration afterwards (if at all)
  140. 140. Copyright 2005 John Cowan under GPL 140 Thoughts of a systems geek ● If applications programmers thought more like systems programmers, the world would be a better place ● If a problem is not interesting, generalize it until it is, then solve the general problem
  141. 141. Copyright 2005 John Cowan under GPL 141 The Unix Way ● Unix has destroyed all its competitors but one (to the point where many people can't even name those other competitors) ● The core of Unix is its software tools philosophy: – the ability to string together lots of little special- purpose tools with generic interfaces
  142. 142. Copyright 2005 John Cowan under GPL 142 The Unix Way ● Everything is a file – Files have a generic interface – All resources in the system could be accessed through these narrow interfaces – Some things were always exceptions – Unix networking broke this philosophy – The Plan 9 research OS restored it, doubled and in spades
  143. 143. Copyright 2005 John Cowan under GPL 143 REST from a Unix viewpoint ● Resources rather than files ● URI space instead of the filesystem ● A slightly different (even narrower) generic interface ● But the focus is the same: a generic shared abstraction, not point-to-point interface coordination.
  144. 144. Copyright 2005 John Cowan under GPL 144 Other coordination environments ● In Linda, you get and put anonymous tuples ● In UNIX shell programming, autonomous programs read and write from pipes ● Plan 9 extends the filesystem to be a universal namespace ● To write a device driver, you implement open and close and read and write and ioctl and ...
  145. 145. Copyright 2005 John Cowan under GPL 145 Final thoughts
  146. 146. Copyright 2005 John Cowan under GPL 146 Has RPC really failed? ● ONC and DCE RPC are the basis of: – Plenty of enterprise software – The widely deployed NFS ● CORBA and DCOM are in lots of industrial- strength enterprise software.
  147. 147. Copyright 2005 John Cowan under GPL 147 REST and WS-* ● In the end, WS-* is just there, like Windows ● REST people need to work to ensure that the WS-* stack is sufficiently rich to be useful to them ● Two different design styles, informed by different needs and values ● They should still share a technology base as much as possible (and no more)
  148. 148. Copyright 2005 John Cowan under GPL 148 You're my only hope ● The only thing that can really make REST work for us all is broad education in: – What, exactly, the REST style is – How to design to it – Why it's a Good Thing ● But that’s why you’re here

×