[Grok-dev] Re: Is there an easy way to customize URL used for grok.REST (use suffix instead of prefix) ?

[Martijn Faassen]

Craeg Strong wrote:
[snip]
> 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 
resource. [snip]

I recommend this technique for ROA applications because it means the URI 
contains all the information necessary for the server to fulfill the 
request. [snip]

The alternative way is called *content negotation*.
[big snip]

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 
representations...]
"""

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 
work.

[snip]
> 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.

[snip]
> 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:

@grok.subscribe(MyApp, IBeforeTraverseEvent)
def restSkin(obj, event):
   if not MyLayer.providedBy(event.request)
         zope.publisher.http.applySkin(event.request,
                                       MyLayer, grok.IRESTSkinType)


> 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 
want.

A rest protocol is a particular rest layer that's published. It has a 
name ++rest++foo. REST views are associated with rest layers.

[snip]
> 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.

Regards,

Martijn