Question

I’m creating a web API based on the new ASP.NET Web API. I’m trying to understand the best way to handle people submitting multiple data-sets at the same time. If they have 100,000 requests it would be nice to let them submit 1,000 at a time.

Let’s say I have a create new Contact method in my Contacts Controller:

public string Put(Contact _contact)
{
    //add new _contact to repository
    repository.Add(_contact);

    //return success
}

What’s the proper way to allow users to “Batch” submit new contacts? I’m thinking:

public string BatchPut(IEnumerable<Contact> _contacts)
{
    foreach (var contact in _contacts)
    {
        respository.Add(contact);
    }
}

Is this a good practice? Will this parse a GET request with a JSON array of Contacts (assuming they are correctly formatted)?

Lastly, any tips on how best to respond to Batch requests? What if 4 out of 300 fail?

Thanks a million!

Answer 1

When you PUT a collection, you are either inserting the whole collection or replacing an existing collection as if it was a single resource. It is very similar to GET, DELETE or POST a collection. It is an atomic operation. Using is as a substitute for individual calls to PUT a contact may not be very RESTfull (but that is really open for debate).

You may want to look at HTTP pipelining and send multiple PutContact requests of the same socket. With each request you can return standard HTTP status for that single request.

I implemented batch updates in the past with SOAP and we encountered a number of unforeseen issues when the system was under load. I suspect you will run into the same issues if you don’t pay attention.

1. For example, the database may timeout in the middle of the batch update and the all hell broke loose in terms of failures, reliability, transactions etc. And the poor client had to figure out what was actually updated and try again.
2. When there was too many records to update, the HTTP request would time out because we took too long. That opened another can of worms.
3. Another concern was how much data would we accept during the update? Was 10MB of contacts enough? Perhaps 1MB? Larger buffers has numerous implications in terms of memory usage and security.

Hence my suggestion to look at HTTP pipelining.

Update

My suggestion would to handle batch creation of contacts as an async process. Just assume that a “job” is the same as a “batch create” process. So the service may look as follows:

public class JobService
{
    // Post
    public void Create(CreateJobRequest job)
    {
       // 1. Create job in the database with status "pending"
       // 2. Save job details to disk (or S3)
       // 3. Submit the job to MSMQ (or SQS)
       // 4. For 20 seconds, poll the database to see if the job completed
       // 5. If the job completed, return 201 with a URI to "Get" method below
       // 6. If not, return 202 (aka the request was accepted for processing, but has not completed)
    }

    // Get
    public Job Get(string id)
    {
       // 1. Fetch the job from the database
       // 2. Return the job if it exists or 404
    }
}

The background process that consumes stuff from the queue can update the database or alternatively perform a PUT to the service to update the status of Job to running and completed.

You’ll need another service to navigate through the data that was just processed, address errors and so forth.

You background process may be need to be tolerant of validation errors. If not, or if your service does validation (assuming you are not doing database calls etc for which response times cannot be guaranteed), you can return a structure like CreateJobResponse that contains enough information for your client to fix the issue and resubmit the request. If you have to do some validation that is time consuming, do it in the background process, mark the job as failed and update the job with the information that will allow a client to fix the errors and resubmit the request. This assumes that the client can do something with the fact that the job failed.

If the Create method breaks the job request into many smaller “jobs” you’ll have to deal with the fact that it may not be atomic and pose numerous challenges to monitor whether jobs completed successfully.