API design for batch updates

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?

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.

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.