Re: Thought: 207 Description Follows

minor note: Content-Location could be used to provide a URI for the 
descriptor document, thus Conneg compatible out off the box.

Nathan wrote:
> 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:06:21 UTC