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

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