Sounds good to me: +1; we should deprecate and remove the support for /*
before the release. Too many options are too confusing :)
Carsten
Felix Meschberger wrote:
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
--
Carsten Ziegeler
[EMAIL PROTECTED]
