Help for bulk actions best practice

[Fabio Martelli <fa...@gmail.com>]

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.

Re: Help for bulk actions best practice

[Edward Siewick <es...@digipro.com>]

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.