[LRUG] REST and Associations

[Eleanor]

On 3 Mar 2007, at 18:59, Tim Fletcher wrote:
> On 27/02/07, Eleanor <eleanor at goth-chic.org> wrote:
>> However in (X)HTML land your application has to provide an interface
>> that allows a resource to be presented in an editable manner, hence
>> the use of a parameter to a GET request to return a representation
>> that can be edited by the browser. In this case you are not using
>> 'edit' as a verb, but as a noun identifying the edit form itself.
>
> I've never understood why there seems to be an aversion to using
> /posts/1 as the 'edit' form. If the current user isn't allowed to edit
> the resource then just a plain 'view' action can be rendered instead.
> That would then be much closer to the raw HTTP usage.

There are many cases when it's valid for a user with editing  
privileges to access a resource both for editing and for non-editable  
viewing, so some way of indicating the difference is required. Many  
people are quite happy with a URI such as

	/some/resource/document?edit=true

but a RESTful approach would favour

	/some/resource/document/form_for_editing

even though this is not in fact REST in action (because the form is  
an unnecessary representation - the client receiving a resource  
should be able to infer an editing form from the resource it receives  
and do the update via a POST request). Architecturally this is all in  
its infancy and we just have to live with that.

So why is the second form better? Aside from aesthetics there's the  
possibility that using parameters to GET requests might make page  
caching more difficult. I don't think that in this case that would be  
likely (Google cache all kinds of funky GET parameters), but why  
introduce unnecessary special cases?

Anyway the problem here is (X)HTML - it's not a RESTful application,  
even though HTTP would never have come into existence without it.  
Whatever we do to get around the defects will break REST in some form  
or another.

> Background reading ([1] and [2]) would suggest that the semicolon (or
> the part after it) is meant to denote "parameters". So the Rails usage
> is valid, but for 'edit' forms unecessary (IMO).

I suspect the use of embedded parameters of this kind is so rare  
because it's hard on the eye. Still, Rails is increasingly popular  
and will as a result make the idiom better known.

> [1] http://en.wikipedia.org/wiki/URI_scheme#Generic_syntax
> [2] http://tools.ietf.org/html/rfc2396#section-3.3

Never believe that because an RFC says something is legal that it's  
also a good idea in practice!

>> A common mistake with pagination schemes is to mandate the number of
>> page entries on the server side, which is not where responsibility
>> should lie (HTTP servers should not maintain state, even if it is  
>> one-
>> size-fits-all 'default' state).
>
> Completely agree. What URI would you use to represent the size of the
> resource collection though? Something that the client could query to
> decide how it wanted to paginate (if at all). Not sure about this
> one... something like /posts;size?

Well one approach would be to use something like

	/posts/statistics
or
	/posts/meta-data

and have it dump an appropriately formatted file containing some  
appropriate meta-data: total posts; posts per date; posts per tag;  
etc. Standard XML or some variant of RDF should both be good for  
this. However that assumes that you're consuming a Web Service.

For standard (X)HTML I think we're stuck with faking this from either  
the server or client. You could keep an item-count in a server-side  
session or else a client-side cookie and use the web application to  
create appropriate RESTful browsing links. Or using AJAX put the same  
functionality into the client interface. I'd be more inclined to the  
server-side option just because it works with javascript missing or  
disabled.


> Leonard and Sam's book
> (http://www.crummy.com/writing/RESTful-Web-Services/) looks like it
> might be useful here!

Definitely looks like one for my bookshelf :)


Ellie

Eleanor McHugh
Games With Brains
----
raise ArgumentError unless @reality.responds_to? :reason