Re: ldp-ISSUE-24 (remain deleted): Should DELETED resources remain deleted? [Linked Data Platform core]

Hi,

On Sun, Oct 21, 2012 at 4:11 AM, Ruben Verborgh <ruben.verborgh@ugent.be> wrote:
> Hi Mark,
>
>> Hmm. Well, the only way I can see that being the case is if the LDP
>> specification is not intended for clients. So, using 404 as an example
>> again, even though servers are required to return 404 after a DELETE,
>> BPR clients can't assume that will be the case.
>
> I can’t see why not.

Because if you define what is expected by the client, then you are
defining a contract; a protocol. And the Web already has one of those
:)

> If S is a BPR server and C is a BPR client, then the following interaction can take place (given sufficient permissions)
>
> C: GET /resource
> S: 200 OK
> C: DELETE /resource
> S: 204 No Content
> C: GET /resource
> S: 404 Not Found
>
> The behavior of the client and server in the above example is compliant to the HTTP spec.

True, but that's not the whole story. What you have there is a BPR
client that can talk to BPR resources, but not to non-BPR resources.
You might also have troubles with non-BPR-aware intermediaries who
assume that DELETE means what RFC2616 says it means, not what the BPR
client and BPR server have secretly (via the LDP spec, which isn't
referenced from any of those messages AFAICT) agreed it means.

> The LDP spec herein mandates that the last request should be a 404 or 410, while the HTTP spec leaves open what should happen.

The HTTP spec leaves open the behaviour of a server. It explicitly
does *not* leave any room for interpretation about what the client can
expect of a DELETE request, because that would be neglecting its
duties as an application protocol.

Mark.

Received on Sunday, 21 October 2012 14:52:30 UTC