Hi all, Ok, as the feedback is positive, I modified SLING-422 to reflect this proposal (with the exception to keep the /* support in addition to the new "trailing slash" support). I start working on these changes and hope to commit them real soon.
Regards Felix Am Dienstag, den 06.05.2008, 11:36 +0200 schrieb Felix Meschberger: > Hi all, > > While trying to implement SLING-422 [1] it occurred to me, that the > SlingPostServlet is anything but REST-ful. For example, it is possible > to have a request for resource /a which at the same might cause a > resoure /x/y to be moved to /e/f and much nastier things. Providing an > accurate response to such operations and acting upon such responses is > almost impossible if not introducing multi-status ... > > Therefore, I propose to simplify the SlingPostServlet as follows: > > * The servlet is modified to execute a single operation per request, > where an operation may be create/modify, delete, move and copy. The > actual operation to execute is indicated by a new parameter ":operation" > which can take the following values: > > <unset> or empty string - create/modify request > "delete" - delete current resource > "move" - move current resource > "copy" - copy current resource" > > * All operations act on the current resource - request.getResource(). > The delete, move and copy operations fail if the current resource is a > non-existing resource. > > * The distinction between create and just modify depends on the > resource: If the current resource does not exist yet it is created. > Special treatment for resource creation happens if the path is > terminated by a slash (as proposed by Carsten and Roy in earlier > messages) or by a slash-star (/*, like currently). Maybe we should > deprecate the /* behaviour and just support the trailing slash behaviour > for consistency with the general perception. The name of the newly > created node is defined as it is today: using special > parameters :name, :nameHint and well-known content such as title. > > * Some operations (create, move, copy) handle a parameter ":order", > which defines the ordering relation of the newly created item (this is > the same behaviour as in the current implementation) > > * The copy and move operation by default fail if an item already exists > at the destination. This behaviour may be overwritten by setting the > ":replace" paramter to "true". This replaces the current "replace" value > for the :copyFlags and :moveFlags parameter. > > * The copy and move operations require another parameter ":dest", which > is the destination path name of the resource. The operation fails if the > parameter is missing. > > * The ":redirect" parameter causes the client to be redirected to the > desired target in case the operation was successfull. This is the same > behaviour as today. > > * The ":status" parameter causes the HTTP status code to be > non-standards-compliant: If the parameter value is "browser", that > status code is always 200/OK, even in case of failure. Otherwise the > status code will reflect the actual status. > > * Regardless of the ":status" parameter value, the response is always > the complete run-down of the operation executed with the actual status > code and eventual exceptions - unless of course if the client has been > redirected after successfull operation and instructed to so by > the :redirect parameter. This is the same behaviour as today. > > * Run-Down of some status codes expected: > > 200/OK - if :status==browser or if the operation succeeded > 201/CREATED - required by a successful move or copy, when the > destination > did not exist yet. Also sent when the current resource was > created > 404/NOT FOUND - if the current resource is missing for copy, move, > delete > 412/PRECONDITION FAILED - if the destination for the copy or move > operation exists and the :replace parameter is not set to > true > (this is consistent with the WebDAV spec for COPY/MOVE in > this > situation). > 302/FOUND - aka temporary redirect, if the operation succeeded and > the > :redirect parameter is set > 500/INTERNAL SERVER ERROR - in case of any processing error, > e.g. an exception being thrown > > > In case of general consensus on this matter, I would modify SLING-422 > such, that it actually encompasses this change instead of just > requesting support for real status codes. > > WDYT ? > > Regards > Felix > > [1] https://issues.apache.org/jira/browse/SLING-422
