Re: [api-craft] A single big call or multiple calls?

[mca]

You're taking about some kind of "batch" mode API. before getting into formats and protocol details, consider this...

1) Batch Integrity
You send ten items in a batch for processing. Nine  process successfully, one fails. What is your response? Fail the entire request? Commit mine and report an error for one?

2) Long-running work
some batches might take processing time. Do you plan on keeping a single request/response line open for the duration? of maybe you want to use HTTP 202 (accepted) and now you need to figure how clients will be alerted when the long-running transaction is done. another HTTP request w/ timing headers? an out-of-band response via email? a registered pub/sub callback URL?

3) Security Issues
sending batch requests can open serious security holes. it's pretty easy to send a request that results in a DDOS experience for servers. and, since this is all in a single request, common prevention tooling is unable to help you. So you need to add some security-checks like payload size, transaction count, timer-checks, etc.

4) Dependency Issues
some batch lists might include multiple actions on the same resource (GET, PUT, DELETE, etc.). is this OK? you might run into an "order of events" issue where you want to create a record, then do something with it. you can't do this in the "wrong" order. you can't send a batch that already knows the ID from a POST since POST will create that ID, etc. 

These are the issues I see repeatedly in attempts to execute batches over the network. there are possibly others that include domain, format, and protocol-specific details.

BTW - i try to NEVER to batch work over the network<g>.

hope this helps.

On Oct 24, 2015 17:28, "Andrei Ro" <ips...@gmail.com> wrote:

Hello everyone,

I need to update multiple resources. What would a good API design do: permit a big call containing all the necessary information for the updates or force multiple small update operations on each resource?

--
You received this message because you are subscribed to the Google Groups "API Craft" group.
To unsubscribe from this group and stop receiving emails from it, send an email to api-craft+...@googlegroups.com.
Visit this group at http://groups.google.com/group/api-craft.
For more options, visit https://groups.google.com/d/optout.

[Manu Whig]

There are also authorization considerations that need to be taken into account. The authenticated user might have authorization to only perform certain actions, or access to only some of the resources or resource types that are submitted in the batch. It can lead to either 

1. an implementation which is very complicated and the more complicated it gets, the more fragile it gets. Fragile code can lead to data integrity issues. OR worse, 

2. workarounds/hacks are added to the code to bypass authorization checks. 

I guess this ties into the batch integrity issue, but I feel authorization issues need to be kept forefront because they span both security and data integrity.

[Cooper Marcus]

Due to the considerations noted below, I always default to assuming that we will not support batch operations, and will instead force multiple operations, each involving a single resource. 

While do many operations might be annoying for a human in a UI, computers are good at that sort of thing - so let 'em do the work ; )

Is there some reason that multiple operations is problematic for you or your API's users, in this case?

Visit this group at https://groups.google.com/group/api-craft.