Should FCR API Guarantee Slug Behavior on POST?
no-reply opened this issue · 4 comments
Both Derby and FCRepo4 currently respect Slug: headers on HTTP POST requests, failing the request if the requested slug can't be applied.
This behavior provides a safe mechanism for clients to request a new resource with a known URI within a given container. PUT can provide a similar mechanism, but only with a more complex set of assumptions about the containment of resources created with PUT requests. The slug approach feels more general.
@tpendragon, @cbeer and I ran into this while testing ActiveFedora with Derby, and had the sense that POST was the best approach for clients aiming for generalized LDP support.
cc: @azaroth42. Is this behavior worth trying to standardize in LDP, via RFC, or ...?
I can imagine e.g. an HTTP header to control how slug conflicts are handled.
👍 to using Slug to create a resource with a client-assigned URI rather than PUT, and to failing a request with a Slug that can't be honored. If you care enough to include the slug, then you probably care that it works.
Standardization ... we can bring it up on the LDP Next CG. I would prefer a best practice here, rather than another header that affects the Slug header. If we need another header, it could just as easily be MandatorySlug.
Standardization ... we can bring it up on the LDP Next CG.
I think at the LDP level, it's probably best to simply follow RFC 5023, keeping Slug as a "client hint to the server".
I think my proposal would be to specify handling of that hint within Fedora implementations, ideally defining behavior well enough that clients can safely predict the resulting resource's URI before sending the request.
If it's useful to us, then it's probably useful to others. If we rely on Fedora specific implementation details, then we can't swap out Fedora for other LDP implementations.