Re: HTTP POST /w LDPRs

Hi,

On Wed, Oct 1, 2014 at 5:36 AM, Nandana Mihindukulasooriya
<nmihindu@fi.upm.es> wrote:
>
> Hi,
>
> The LDP spec says,
>
> [[
> Per [RFC7231], this HTTP method is optional and this specification does not require LDP servers to support it. When a LDP server supports this method, this specification imposes no new requirements for LDPRs.
> ]]
>
> In other words, LDP doesn't restrict the behaviour of POST any more than what HTTP does. So if an application allows POST and if those POSTs happen to create something, technically it is not a violation of the LDP spec, is it?
>
> The reason for this clarification is that we have a test in the test suite that uses the POST-create pattern to check the interaction model by looking at whether a response to a POST on an LDPR contains a 201 code and a location header.
>
> [[
> CommonContainerTest#testRequestedInteractionModelCreateNotAllowed
> Resources with interaction model of only ldp:Resources shouldn't allow container POST-create behavior.
> ]]
>
> Though this would work in most practical scenarios, IMHO the condition checked by this test is not imposed by the spec. WDYT?
>
I think fair point but rare case.  Perhaps the tests could go a step
further and ensure that a containment triple wasn't added, instead of
just looking at the response status code.  Another test would be to
instead of doing a POST-create, the test could DELETE a contained
resource and ensure that the containment triple isn't removed on
successful delete of LDPR.

In general, the approach to testing is that we'd like to automate
everything and it to be cover 100% of the implementations and cases.
Reality is, sometimes an implementations, such as the one you outline,
would need to validate the requirement manually.  The EARL results
have a way to capture it was done this way by marking as manual and
supplying comments.  Though I think we'd want to avoid using this
approach.  I'm advocating that we get the automated test as complete
as possible but use an exception approach when not practical to
automate covering all cases.

Thanks,
Steve Speicher
http://stevespeicher.me

Received on Wednesday, 1 October 2014 12:18:58 UTC