Re: ISSUE-58: the simple solution to inlined membership - ISSUE-45

hello richard.

On 2013-05-18 10:06 , "Richard Cyganiak" <> wrote:
>No, the reason was that POST is HTTP's catch-all extension point for
>"other" operations, and it would be bad to "use up" that extension point
>on all LDP-managed resources. LDP implementers should have the liberty of
>using POST to an LDPR for other things beside append.

my favorite topic! i have used up all HTTP methods, now what? ;-) sorry,
but i really cannot resist...

you cannot "use up" all HTTP methods. you model all the interactions with
your resources as self-describing interactions. for each of those
interactions, you look at whether they are safe and idempotent and pick
GET if they are, they delete things and pick DELETE if they do, they are
idempotent but not safe and pick PUT, and otherwise you pick POST. the
fact that early writings about HTTP/REST hardcoded the operation
names/semantics is more historical at this point, and REST has moved on to
focus on the *interaction semantics* when picking a method, because that's
what matters when it comes to handling the HTTP methods in the web's

long story short: don't worry, you can never "use up" all HTTP methods.
when you use POST to append, that's fine and just make sure it's
self-describing. when you add other interactions that also use POST,
there's no conflict because these interactions should be self-describing
as well.

in a nutshell, it's the same as having various "submit" buttons on an HTML
form: they all go to the same form/@action URI, but since you're pressing
a different button, your interacting with the resource in a different way.



Received on Saturday, 18 May 2013 17:29:27 UTC