See inline
From: open...@googlegroups.com [mailto:open...@googlegroups.com] On Behalf Of mark Kharitonov
Sent: 26 June 2011 13:36
To: open...@googlegroups.com
Subject: [openrasta] Is there a description of how OpenRasta implements the various features described in the RESTful Web Services book?
I am sure, that it is possible to implement all of these, but I am interesting in the OR way of doing it:
· Compression
Not done by us, but there’s pull requests for it so it’s gonna be coming up soon
· Conditional Get
I’ve not found a nice way to deal with this at the API level so far, but I’m open to suggestions.
· Look-Before-You-Leap Requests (page 247)
100 continue is usually handled by the hosting environment, not by OR, so there’s no support for it as such, because we don’t get a chance to respond in the asp.net pipeline.
· Faking PUT and DELETE (page 250)
There’s a uri decorator that supports the /resource!PUT and /resource!DELETE and fakes them when receiving posts.
· Prepending URLs with the version element, like v1 (page 233)
I’d recommend against that too, versioning at the uri level is usually a sign of poor design. That said URI manipulation is usually done by Uri decorators, so it’s rather easy to do.
· Getting different representations of the same resource (page 215)
Content negotiation is done out of the box. They’re prioritized usin a q= in media type registration.
· WADL - is it possible to generate it from the OR configuration?
Yes but I’d recommend against it. You can have a look at the mailing list history, there’s some lengthy conversations about that:)
Thanks.
So for the representations, it’s rather simple. Provided you have a registration that looks like .Has.Resource<Home>().Uri(“/home”).Handler<HomeHandler>().XmlDataContract().And.JsonDataContract() (or equivalent syntax for OR2)
Both representations will be available on the same URI and can be conneg’d by the client using the Accept: header. If you want one or the other to be priroritized on the server (because, say, the client sent Accept: application/xml,application/json), then you can override the media type using .MediaType(“application/xml;q=0.5”) and whichever codec with the highest q value will be prioritized
From: open...@googlegroups.com [mailto:open...@googlegroups.com] On Behalf Of mark Kharitonov
Sent: 26 June 2011 20:55
To: open...@googlegroups.com
Subject: Re: [openrasta] Is there a description of how OpenRasta implements the various features described in the RESTful Web Services book?
Thanks for the reply.
There is a few points still unclear to me:
1. Do you have an example of how can I GET different representations of the same resource? I did not quite understand your reply. Sorry.
2. About WADL. I have read a few discussions following your advice. I think I understand a bit more now. Reading them made me think about my server, but it is a subject for another question.
You can use URI decorators to add .xml and .json at the end of each media type, it’s somewhere on the wiki
From: open...@googlegroups.com [mailto:open...@googlegroups.com] On Behalf Of Mark Kharitonov
Sent: 26 June 2011 21:57
To: open...@googlegroups.com
Subject: Re: Re : RE: [openrasta] Is there a description of how OpenRasta implements the various features described in the RESTful Web Services book?
I have just realized, that item (2) is trivial - one has to repeat the .Has.Resource statement for the same resource twice, each time giving different contract and different URL.
Maybe there is a more compact syntax, the one that avoids duplicating the configuration entries?
On 26/06/2011, at 23:49, mark Kharitonov wrote:
Two questions:
1. What is your reservation pertaining the advice given in the book to expose the different representations using different URIs, rather than HTTP headers?
2. Is it possible to adopt the scheme described in the book? So that http://bla/MyResource.xml returns XML representation and http://bla/MyResource.json returns JSON representation, provided of course, both are supported by the resource.
Thanks.