Re: Thought: 207 Description Follows

Hi,

I believe TimBL has suggested this previously with a 208, however both 
207 and 208 are already assigned or mentioned in various DAV 
communities, thus 209 or higher would have to be used I believe.

Personally, I like the idea a lot, and the usefulness for IoT is great 
too - any convergence between the semantic web and IoT, especially at 
HTTP and descriptor level, would be great.

Best,

Nathan

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
> 
> 
>

Received on Wednesday, 28 March 2012 09:04:17 UTC