Chris, > For instance, say I wanted to implement a publish/subscribe > system using > HTTP. One way to do this uses header information to > communicate between > the publisher and subscriber -- the server may add > 'X-Subscribable: URI' > to any resource that can be subscribed to, the client may add a > 'X-Subscriber: URI' header when it wants to subscribe to a resource. > > http://rest.blueoxen.net/cgi-bin/wiki.pl?HttpEvents#nidNL > > While my final solution might be something completely different, the > idea that I'm precluded from an approach because I can't read or add > headers, which are core to HTTP, seems fundamentally flawed.
In this case that would make sense. And the Restlet framework will support this in a convenient way at the connector level. You will be able to pass your "X-Subscribable" and "X-Subscriber" URIs either as call attributes or as call properties (via a subclass of Call). > Viewing the 'Accept' header was just to see what Firefox was > *actually* > sending, versus what Restlet interpreted it as. Given the current > browser market this seems unavoidable :-) Absolutely, doing some browser specific handling is necessary. The preferences stored in the Call object contains all the details of HTTP (multi-preferences and quality levels) so you shouldn't be worried about losing any bit of info. It's just parsed for you and easily manipulable via a higher level Java API. But I understand that you need to 'see' the raw bits in the HTTP header :-) > More generally: one of the benefits of basing an application > on HTTP is > that the message is transparent. I think it's useful to keep this > benefit even though 98% of the time we're interacting with > the messages > at a higher level. Agreed. With org.restlet.Call we interact at a higher-level, in a protocol-neutral way, but must are definitely based on HTTP which is the de facto standard for REST applications. Thanks, Jerome
