Hey John,
I take your point for sure - the only thing id say on this would be
that there is argument (both for and against) of holding this type of
resource representation in the request metadata as opposed to the
concrete URI. Both ways are "restfull" as it were, id say its a matter
of preference / use case. I need to check, but If you wanted to set
the accept and content-type headers we have this partial function in
lift rules:
var determineContentType: PartialFunction[(Can[RequestState],
Can[String]), String] = {
case (_, Full(accept)) if this.useXhtmlMimeType &&
accept.toLowerCase.contains("application/xhtml+xml") => "application/
xhtml+xml"
case _ => "text/html"
}
I've never used it, but it might be appropriate here. If not, perhaps
one of the other guys can chime in and correct me :-)
Cheers
Tim
On Nov 8, 9:34 pm, "John Nilsson" <[EMAIL PROTECTED]> wrote:
> On Sat, Nov 8, 2008 at 1:36 PM, Tim Perrett <[EMAIL PROTECTED]> wrote:
> > Otherwise, im looking to create a service that operates like this:
>
> > GET /articles.xml => serves as xml
> > GET /articles.js (or .json, whichever is more appropriate) => serves
> > as json
>
> > and
>
> > GET /articles/1234.xml
> > GET /articles/1234.js
>
> Just curios, but whats wrong with
>
> GET /articles/1234 HTTP/1.1
> Host: example.com
> Accept: text/xml; q=1.0, application/json; q=0.8
>
> ?
>
> BR,
> John
--~--~---------~--~----~------------~-------~--~----~
You received this message because you are subscribed to the Google Groups
"Lift" group.
To post to this group, send email to [email protected]
To unsubscribe from this group, send email to [EMAIL PROTECTED]
For more options, visit this group at
http://groups.google.com/group/liftweb?hl=en
-~----------~----~----~----~------~----~------~--~---
