API design for batch updates

rubyonrails-talk
1

Hi,

I'm adding an API to a Rails app where clients will be able to create records on the DB. I've been reading around but didn't find a good set of characteristics that the API should have. These are the things I have in mind.

- Access controlled by token and over ssl - Versioned so I can improve it safely - REST based (though I'm not obsessed with it, the scope of the API is quite reduced and affects just 2 resources in exactly the same way) - I will limit the content length to avoid too big request and force clients to breakdown the requests if needed

Using the API the users will be able to create, modify or delete two types of very basic resources. Updates and deletes are not expected to be very frequent actions anyway.

For example for a create action I'll take JSON arrays included in the request body as input from the clients:

{ "entries": [ { "ind_id":11 , "elem_id":22, "value":33.44, "scope":"22-2012" }, { "ind_id":13 , "elem_id":null, "value":35.45, "scope":"22-2012" }, { "ind_id":14 , "elem_id":24, "value":63.44, "scope":"22-2012" }, { "ind_id":15 , "elem_id":25, "value":73.74, "scope":"22-2012" } ] }

My questions and worries:

- Initially I thought of creating an array of hashes and pass that to the create method. But a simple test showed me that if one fails the rest go through and I don't get any straight indication of which one failed. So I think I should get all the items in one post and planned but then create the records one by one, that way I can collect data if any fails and report back to the clients. Is that a bad idea?

- I guess there should be a background job taking care of inserting the records to the DB, I'm not sure how would I communicate back with the client?

Any good hints regarding this topic?

2

Initially I thought of creating an array of hashes and pass that to the create method. But a simple test showed me that if one fails the rest go through and I don’t get any straight indication of which one failed. So I think I should get all the items in one post and planned but then create the records one by one, that way I can collect data if any fails and report back to the clients. Is that a bad idea?

Can’t think of a reason why it could be a bad idea…

I guess there should be a background job taking care of inserting the records to the DB, I’m not sure how would I communicate back with the client?

The method of status communication would depend on the type of your client. Any feasible publisher subscriber pattern implementation should be your best bet. Polling should be the last option.

If its a web client, you can check out websockets for resource efficient real-time communication.

3

Vibhor wrote in post #1086437:

Initially I thought of creating an array of hashes and pass that to the create method. >

Can't think of a reason why it could be a bad idea...

Performance wise. I imagine it would be faster to pass the array of hashes to the create method. But then I'd need to build some mechanism to verify the success and would probably be even worse than creating one by one.

I guess there should be a background job taking care of inserting the

records to the DB, I'm not sure how would I communicate back with the client?

The method of status communication would depend on the type of your client. Any feasible publisher subscriber pattern implementation should be your best bet. Polling should be the last option. If its a web client, you can check out websockets for resource efficient real-time communication.

Each company using the product will implement their own client to use the API. JSON over http so I guess that makes it a web client. I should find out more about websockets thanks for the pointer.

Thanks Vibhor.