Re: Thought: 207 Description Follows

On 3/28/12 4:46 AM, Kjetil Kjernsmo wrote:
> Hi all!
>
> I hope it is OK that I just burst in here without having followed the
> discussion. Admittedly, I haven't been terribly interested, I've always
> enjoyed the 303 dance, I wrote the code and it was easy, and the IR/NIR
> distinction has always served me well. However, I also see that it is a bit
> painful to have to do follow a redirect, both for end users and for code, and
> the bit about cachability, CORS problems, etc makes it clear there is room for
> improvement.
>
> So, how about a new HTTP response code, e.g. 207 Description Follows? I.e., it
> is like 200 OK, but makes it clear that what you're dereferencing is not an
> IR. Instead, you're getting a description of the thing.
>
> This would have implications well beyond our community, GETting the URI of a
> device in the Internet of Things would  also reasonably return a 207. Without
> having thought too deeply about this, I suggest this means it satisfies the
> orthogonality of specifications constraint.
>
> I just quickly hacked a server to test how browsers would react to a 207 code,
> and all browser I have did it gracefully. I therefore conjecture that clients
> needing to know the IR/NIR distinction will be able to figure it out by looking
> at the status code only, those that need not, would not need to be bothered.
>
> Deployment costs should thus be very low. We're also working to get our code
> into Debian (older versions are already in Ubuntu), so if we have this settled
> before Debian Wheezy freezes in June, it would be available in mainstream
> hosting solutions late this year. I think that's a key, because many users
> control very little of their server setup, and custom code is "dangerous", but
> with the support of Debian the costs for hosters are marginal.
>
> Naively Yours,
>
> Kjetil
>
>
Long time!

"Link:"  headers, response codes, an even a new DESCRIBE method are all 
viable solutions. The only issue is how this plays with the Web as it 
currently exists re. providing a really simple segue for those that 
aren't interested in Linked Data fidelity today. Basically, how do we 
make Linked Data osmotic will remaining within the Web's "deceptively 
simple" architecture.

Poor HTTP is too clever, really. It let's you have a conversation that 
sometimes helps you make better decisions. "You" in this context is a 
machine exchanging messages over a network with another machine.

Next we have HTML in the mix, widely used, and still the dominant entry 
point for HTTP experience albeit via hypertext links as opposed to 
hyperdata links.

Back to your suggestion. Bearing in mind the above, how do those that 
work at the HTML level play ball? At least with "Link:" headers we could 
encourage the best practice of mirroring all "Link:" responses in the 
<head/> sections of (X)HTML resources which plays well with discovery 
patterns widely adopted across the Web 2.0 landscape.

Your solution works, but I am unconvinced about its ability to keep the 
"deceptively simple" aspect of the Web platform intact i.e., make it 
easy for existing Web users and developers to wonder into the Web's data 
space dimension, with minimum disruption to existing usage patterns.

Hash URIs work if we accept that the Web is ultimately a global jigsaw 
puzzle with lots of fine-grained and coarse-grained puzzle pieces. Each 
Web user is a creator or user of the games puzzle pieces.  The option 
for hashless (or slash) URIs simply adds dexterity to this wonderful 
system, as it currently exists.

-- 

Regards,

Kingsley Idehen	
Founder&  CEO
OpenLink Software
Company Web: http://www.openlinksw.com
Personal Weblog: http://www.openlinksw.com/blog/~kidehen
Twitter/Identi.ca handle: @kidehen
Google+ Profile: https://plus.google.com/112399767740508618350/about
LinkedIn Profile: http://www.linkedin.com/in/kidehen