Hi.
RFC2616, section 9.1 Safe and Idempotent Methods, provides a couple
dichotomies that ought to be considered the default for design. These
suggest how authentication and access to the methods might be arranged,
which is a key consideration in how you might divvy up the modules.
A "safe" method is essentially informational; access for a safe method
can be allowed to users and devices with a need for data or to
understand the structure of a service. This, as opposed to methods
intended to change the service or its data, which should require
allowing access only to users and devices with thorough knowledge of the
internal structure of the service. And, authorization to make changes.
There are "safe" methods that should not be anonymous, since they
provide access to possibly sensitive information. There are others that
can be handled as anonymous. (As a fine point, even anonymous methods
should be required to authenticate, so that the events can be identified
in the logging without requiring special exceptions.) A GET for a log
extract is an example of a safe method that should typically require
authentication and authorization.
An "idempotent" method should be repeatable, through error conditions,
engineer impatience or other situations, with only a one-time effect on
the service. A dozen identical idempotent methods blasted at a service
should have the same result overall as the first that actually worked.
All "safe" methods should be idempotent. Various other sorts should be
as well. For instance, it should be ok for a client to request a delete
of the same identity repeatedly. All attempts after the first success
should produce an error response. But, the service shouldn't otherwise
be troubled. A REST call that deletes the next identity in serial
order, or maybe "all identities created 10 minutes ago", wouldn't be
idempotent.
Edward Siewick
On 03/05/2013 05:19 AM, Fabio Martelli wrote:
Hi All, I'd like to know the best practice to implement the bulk action feature.
Is there someone that can help me with the following points?
1. Number of different implementations:
just one REST method for all the "bulkable" functionalities or one per
one (bulkDelete, bulkSuspend, bulkReactivate, ...)
2. Method:
GET, POST, DELETE (in case of bulkDelete), ...
3. REST method input:
a list of identifier or a wrapper (e.g. BulkActionTargets) for that list
Any comment/remark is welcome.
Thank you in advance.
F.
