[Grok-dev] Re: Is there an easy way to customize URL used for
grok.REST (use suffix instead of prefix) ?
faassen at startifact.com
Mon Jun 2 12:12:19 EDT 2008
Craeg Strong wrote:
> In the future I would like to try making the *same* URL support both an
> HTML View and an XML "View" via content negotiation.
> That was the original vision (as I understand it) for REST, and it would
> be great if Grok made that easy to do.
Actually I deliberately didn't implement content-negotation. I heard
that Rails initially did but went back from it as well. The drawback of
content-negotiation is that you can't easily test your REST views with a
web browser anymore, and caching also becomes harder.
"Restful Web Services", an O'Reilly book I've been consulting quite a
bit, seems to agree with me on this approach:
If a server provides multiple representations of a resource, how does it
figure out which one the client is asking for? [snip]
There are a number of ways to figure this out within the constraints of
REST. The simplest, and the one I recommend for the Resource-Oriented
Architecture, is to give a distinct URI to each representation of a
I recommend this technique for ROA applications because it means the URI
contains all the information necessary for the server to fulfill the
The alternative way is called *content negotation*.
It's RESTful to keep this information in the HTTP headers, and it's
RESTful to put it in the URI. I recommend keeping as much of this
information as possible in the URI, and as little as possible in the
request metadata. [...as request metadata more easily get lost when URIs
are passed around, and computers are bad at dealing with unexpected
That said, I'm not against making this possible absolutely. A directive
to grok.REST which could specify the content-types and then being
allowed to register multiple sets for the same requests could be made to
> By partitioning the URL space with 'xml', I am in effect encoding the
> content type in the URL, which is a REST no-no, but a very convenient
> and I suspect widely practiced work around :-)
I think some REST people at least disagree that it's really a REST no-no.
> Cool! I am sorry to be so dense, but is the "...apply the rest skin"
> where I return a new instance of my grok.REST subclass?
No, I mean the bit I talked about earlier:
def restSkin(obj, event):
if not MyLayer.providedBy(event.request)
> I admit I have not yet grasped the full zen of IRESTLayer, REST,
> RESTProtocol, etc.
Yeah, it's a bit involved. It's similar to skins.
A skin is a particular layer that is published. It has a name
++skin++foo. Views are associated with layers. Layers can extend other
layers and thus you can compose bigger layers out of smaller ones if you
A rest protocol is a particular rest layer that's published. It has a
name ++rest++foo. REST views are associated with rest layers.
> Yes, something like that which also incorporates my other use case
> described above would be fantastic!
> I am way too much of a newbie to contribute code, but can contribute the
> writing and executing of tests and documentation.
I suggest you get some experience getting this pattern going with REST,
and then start a new thread based on your experiences. It looks like we
want something that's like a model and a view at the same time. This can
be accomplished with views on views too, by the way. Perhaps that is the
cleaner solution; but I'm not sure.
More information about the Grok-dev