W3C home > Mailing lists > Public > public-lod@w3.org > April 2011

Re: Proper usage of HTTP for LD servers, clients, crawlers etc.

From: Markus Luczak-Rösch <markus.luczak-roesch@fu-berlin.de>
Date: Tue, 12 Apr 2011 20:03:02 +0200
To: <public-lod@w3.org>
Message-ID: <C9CA6076.7EEF%markus.luczak-roesch@fu-berlin.de>
Dear Mark,

thanks for the discussion on this. As you note it as well, it seems
reasonable to forward this to the LOD list and the SPARQL Working Group.

I see the point that for most applications it is reasonable to have some
notion of "null" in the message-body. From the perspective of usage
mining, which is what we are doing, it aggravates things and 204 would be
the better choice. I am curious about what most of the people here think
about this. I would prefer lines of code that handle the HTTP protocol
properly in contrast to implementing "no-result-handling" proprietary for
each of my applications.

Once again, thanks for the input.

Cheers,
Markus

On 09.04.11 00:50, "Mark Baker" <distobj@acm.org> wrote:

>Hi Markus,
>
>On Thu, Apr 7, 2011 at 8:18 AM, Markus Luczak-Rösch
><markus.luczak-roesch@fu-berlin.de> wrote:
>>Hi Mark,
>>
>>thanks for the reply, but I do not see the point, where 204 contradicts
>>to
>>what I am saying? If there is no result for a query, the server should
>>respond 204 and nothing more (no message-body). By now this message "no
>>result" is obviously responded as 200 plus certain message-body. I would
>>be thankful if you give me the point where I am wrong with my proposal.
>
>Ah, I misunderstood you then.  If you're not going to return anything
>at all, 204 would be fine.
>
>That said though, there's an important reason you don't see the 204
>response in the wild; it usually requires separate code paths. For
>example, if I were writing a JSON-consuming client, I'd rather feed
>all response data into a JSON parser rather than say "if status ==
>204: response = []".
>
>The fact is that most media types already have their own notion of
>"null" (and some have multiple, e.g. JSON) that is different than an
>empty message, and it's usually easiest and best to reuse them even if
>it does cost a few extra bytes on the wire.
>
>BTW, if you want to forward this to the list, feel free.
>
>Mark.
>
Received on Tuesday, 12 April 2011 18:00:48 UTC

This archive was generated by hypermail 2.3.1 : Sunday, 31 March 2013 14:24:32 UTC