INFORMATION APOCALYPSE

Only Send What You Need

		      <p>Managing RESTful AJAX operations is an <a href="http://www.ajaxpatterns.org/RESTfulOperations">open 
    problem</a>. While I say that <a href=/?m=asynchronous-rest">aspects of managing HTTP requests, and designing 
    UI feedback cannot be understood in isolation and must be integrated</a>, 
    I still think there are two distinctive and separate issues to consider.</p>
  <p>For starters, HTTP has always been stateless, that's it's fundamental 
    form. So in some ways, talking about asynchronous representational state 
    could be pretty meaningless, but it becomes far more interesting when 
    we consider the differences between "pages", "services" 
    and "resources".</p>
  <p>The basic concept of the HTTP protocol is of a set of request types - 
    the verbs that act on the nouns representing each resource. The fundamental 
    format of a resource is a page, but practically, it could be anything. 
    In contrast, the concept of a web service is often related to the notion 
    of a remote procedure call, treating HTTP as the way to transmit access 
    an object and return the results of a method, usually without needing 
    to consider the URI as representing an actual resource. Remote procedure 
    calls mostly return generic data structures or a "message", 
    usually in XML format.</p>
  <p>In AJAX land where the dominant metaphor of pages is changing towards 
    one of "containers", there are two kinds of requests:</p>
  <ol>
  • Requests that load data structures or content to be displayed in the user interface
  •     <li>Requests that modify and store content on the server</li>
      </ol>
    

    I haven't yet seen much discussion that attempts to separate the distinct issues that arise from these two separate aspects. I think the first of these aspects is pretty well understood - the notion of "only load what you need" is familiar to many developers, but it's the second that interests me the most.

      <p> GET and POST are so overused, it's often easy to forget that PUT and 
        DELETE have the potential to be useful too, although I think that the 
        dominant trend has followed a pretty much ineviatable path of least resistance 
        in browsers and server languages, being largely responsible for blocking 
        the potential ascent to a RESTful nirvana.</p>
      <p>If <span class="code">http://mysite.com/item/my-title</span> was the 
        URI location of a particular content item, a GET request should return 
        a standard HTML page, unless the request specifically instructs the server 
        to deliver another content type (plain text, javascript, or XML). To extend 
        this further, the application should enable the ability to make a POST 
        or PUT request to this URI. In many implementations I've seen, the application 
        will break if a POST does not contain an exact set of particular fields. 
        Where the overlap of AJAX and REST gets exciting is the potential for 
        making use of a server controller that is smart enough to trigger a unique 
        persistant update based on the particular HTTP headers and fields sent 
        with the request. For example, you could send <span class="code">title=A+changed+title</span> 
        or <span class="code">title=A+changed+title&amp;description=A+new+description</span> 
        to the same URI, and expect a coherent update to occur in each case.</p>
      <p>So what if a web application did expose a full range of structured data 
        through a pure URI format? Whether AJAX or not, this approach changes 
        the notion of a resource from representing a page, or a stream of structured 
        data, towards representing a synthetic object. The cannonical notion of 
        these objects is the noun "item". The noun "page" 
        would be another one of these objects, as would "book", "quote", 
        "note", "event", and so forth.</p>
      <p>I'm interested in developing 
        this kind of resource framework at a more fundamental level - a meta-vocabulary 
        for constructing content relationships - although to a greater or lesser 
        extent, all dynamic sites do this anyway. What few sites do however, is 
        expose their vocabulary directly through the URI. I'm starting to see 
        some interesting possibilities.</p>
      
      <div class="related">
      	<h5>Further Reading:</h5>
      	<p>› <a href="http://www.atomenabled.org/developers/api/atom-api-spec.php" title="Atom API Specification">Atom 
          API Spec (Pre-Draft)</a><br>
          › <a href="http://www.megginson.com/blogs/quoderat/archives/2005/02/14/rest-design-questions/" title="The C Word">REST 
          Design Questions</a><br>
          › <a href="http://bitsko.slc.ut.us/blog/atom-neutral-api.html" title="Representation neutral">Can 
          the Atom API be representation neutral?</a><br>
    	  › <a href="http://www.onlamp.com/pub/a/onlamp/2005/04/22/bosworth.html" title="RSS for data">Bosworth's Web of Data</a><br> › <a href="http://c2.com/cgi/wiki?InterfaceSegregationPrinciple" title="c2 wiki - Interface Segregation Principle">The Interface Segregation Principle</a><br> › <a href="http://www.manageability.org/blog/stuff/rest-explained-in-code" title="REST explained in code">Why REST is better - explained in code</a></p>
      </div>			
    

    About This Book

    This is archived content. Probably useless now.