OK. So it appears that I am blind - the answers were right there and I just didn't see them. Thanks.
As for abstraction and protocol independence part, I'll just have to say I respectfully disagree and leave it at that for now; I'd love to have the discussion, but I don't have the bandwidth for it right now. And I should probably spend a little more time with the package before I form any strong opinions. Oh, and thanks for all the hard work. Restlets is one of the few packages that I've worked with that does what I need and 'just works'. I'd really love to contribute, but right now I have other things demanding my attention. --Chuck -----Original Message----- From: Jerome Louvel [mailto:[EMAIL PROTECTED] Sent: Monday, February 12, 2007 12:18 PM To: [email protected] Subject: RE: RE: Re: Response Headers Chuck, The Javadocs do have the info about the HTTP headers, in addition you can check this FAQ entry: http://www.restlet.org/faq#05 >From an HTTP protocol point of view, headers are indeed first class citizens. >Our HTTP connectors actually use an HTTP specific API with direct access to >headers. At the Restlet API level, our focus is not the HTTP protocol, but the >Web application developer needs. We don't want people to manually deal with >HTTP headers, their formatting or parsing. Instead we provide an >object-oriented API that provides a full mapping of information available in >HTTP without requiring developer to know how to parse/format, etc. Also, HTTP >as both communication aspects (pipeline, persistent connection, chunk >encoding, etc.) and "pure" application aspects like the request URI, method, >body and a subset of headers. By exposing only the "pure" HTTP application >aspect into the Restlet API, we shield the application developer from >manipulating/interfering with the communication aspects (we let the HTTP >connectors deal with that). As for the protocol independence. To be more precise, the Restlet API is a direct and complete abstraction of the HTTP protocol ("pure" application aspects) that can also be use to work with other "compatible" protocols like FILE, SMTP, FTP, JDBC, etc. If the protocol doesn't support a feature of HTTP (like redirection), then the connector will simply ignore it. Protocol independence doesn't mean that the application developer can or should ignore the actual protocol used. Just that he can use the same API to work with several protocols, nothing more. I hope this clarifies. In any case, your feed-back is important so don't worry about complaining too loudly as long as the discussion stays constructive. There is always an opportunity to influence changes in version 1.1, 2.0, etc. Best regards, Jerome > -----Message d'origine----- > De : Chuck Hinson [mailto:[EMAIL PROTECTED] Envoyé : lundi 12 > février 2007 15:27 À : [email protected] Objet : RE: RE: Re: > Response Headers > > I don't know what the 1.0.0 snapshot javadocs have in them so ignore > this if it's already addressed, but > message.getAttributes() make no mentions of being able to retrieve > http headers nor what one uses for the key name (I'm guessing the > header name, but it'd be nice if the docs say so). > > It'd also be nice if the methods that wrap access to the headers were > more explicit about what headers they manipulate. > > I'm also a little puzzled at the idea of considering headers as > lower-level artifacts; it seems to me that, http being an application > protocol, the headers are first-class citizens. > When I'm attempting to implement a spec that's based on http and it > says that such-and-such a header must be set, then that's an important > thing for me to be able to do. > > I'd also argue that it's a waste of time to try to make Restlets > protocol agnostic. While REST certainly doesnt specify an application > protocol, at this point there is only one and http is it. Google > around for leaky abstractions and protocol independence. You'll find > that true protocol-independence is rarely acheived and almost always > costs more than its worth in additional complexity. (For example, how > would you support an underlying protocol that doesn't have the concept > of redirection - all those redirect methods become pretty useless.) > > But hey - you guys are the ones doing the work, so I'm not going to > complain too loudly. > > --Chuck > > -----Original Message----- > From: Jerome Louvel [mailto:[EMAIL PROTECTED] > Sent: Monday, February 12, 2007 4:38 AM > To: [email protected] > Subject: RE: Re: Response Headers > > > Hi Chuck, > > All standard HTTP headers have an equivalent class/property in the > Restlet API. It was a deliberate choice to not expose those headers as > first-class citizens, because we consider them as lower-level > artifacts and because we want to support multiple protocols via the > same API. > > However, you do have access to those raw headers via the > request.attributes property. You can also add non standard HTTP > headers if required. See the Javadocs for details: > http://www.restlet.org/docs/api/org/restlet/data/Message.html# > getAttributes( > ) > > Best regards, > Jerome > > > -----Message d'origine----- > > De : Chuck Hinson [mailto:[EMAIL PROTECTED] Envoyé : > lundi 12 > > février 2007 06:36 À : [email protected] Objet : RE: Re: > > Response Headers > > > > Umm. OK, thanks. Not was I was expecting, but I'll take it. > > > > However, the more generic question is then how do I set an > arbitrary > > HTTP header (entity or response) on a response? > > > > --Chuck > > > > -----Original Message----- > > From: news [mailto:[EMAIL PROTECTED] On Behalf Of Vincent > > Sent: Sunday, February 11, 2007 8:51 PM > > To: [email protected] > > Subject: Re: Response Headers > > > > > > > > > Maybe I'm blind, but I don't see how to set a header in a > response. > > > > > > I need to set the Location header on a response to a POST, > > but I can't > > > > > seem to find the right place to do that. What am I missing? > > > > > > response.setStatus(Status.SUCCESS_CREATED); > > response.setRedirectRef(request.getRootRef() + <uri>); > > > > -Vincent.
