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" <[email protected]> wrote: >Hi Markus, > >On Thu, Apr 7, 2011 at 8:18 AM, Markus Luczak-Rösch ><[email protected]> 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. >
