Re: ldp-ISSUE-59 (recursive-delete): Reconsider usage of Aggregate/Composite construct to get predictable container delete behavior [Linked Data Platform core]

hello steve.

On 2013-03-20 5:34 , "Steve Speicher" <sspeiche@gmail.com> wrote:
>One thing I'm not hearing is feedback on part a), is this an
>improvement or not?  Or are you saying, until we have a clear
>direction for b) then you can answer a)?

i think a is a big improvement, and it seems like i did not make that
clear enough. afaict, it's going in the direction i was suggesting a while
ago (and earlier in this thread), saying that there are just containers,
and they manage whatever you POST to them. that's simple and clear.


>You might be orphaning but why is that a big problem?  The client
>knows it is doing this by knowing what DELETE does, if it cares about
>the links it should keep a reference to them or not do the DELETE.  A
>server could run some cleanup tasks to remove orphan resources, if it
>thinks it is a problem, or place them in some server-managed special
>container say called "orphans" (application-specific behavior).  I
>would not refer to them as orphans or zombies, it is quite possible
>that an external application is holding a reference to that member
>resource and therefore it is not orphaned in the web sense...just the
>managing server doesn't have a client requested container to leave it
>in.

it's true that orphaning is not against REST, but it is against HATEOAS).
it makes it hard to build RESTful applications that are able to do their
job by just following links. if you cut off all links, then unless you
have clients remembering them, these resources can never be found again,
so you couldn't build an application doing "garbage collection", for
example. you could do that internally, of course, but how long do you keep
the resources around that aren't linked to from anywhere anymore (within
the scope of your service), but you still want to keep them for a while?

there are AtomPub implementations that do what you're suggesting and will
create a "deleted entries" collection to which entries are moved when they
are DELETEd from regular collections. it's basically what UIs have as
trash can metaphors. but even then the question is how to support "empty
trash", and whether the trashed resources then should really go away, or
you would still keep them around (for an "undo empty trash" operation,
maybe) but they would become undiscoverable.

generally speaking, i try to design REST services in a way so that there
always is a discovery story for all resources.

cheers,

dret.

Received on Wednesday, 20 March 2013 18:17:53 UTC