[ACCEPTED]-Bulk Collection Manipulation through a REST (RESTful) API-rest

You might want to think of the change task 24 as a resource in itself. So you're really 23 PUT-ing a single object, which is a Bulk 22 Data Update object. Maybe it's got a name, owner, and 21 big blob of CSV, XML, etc. that needs to 20 be parsed and executed. In the case of CSV 19 you might want to also identify what type 18 of objects are represented in the CSV data.

List 17 jobs, add a job, view the status of a job, update 16 a job (probably in order to start/stop it), delete 15 a job (stopping it if it's running) etc. Those 14 operations map easily onto a REST API design.

Once 13 you have this in place, you can easily add 12 different data types that your bulk data 11 updater can handle, maybe even mixed together 10 in the same task. There's no need to have 9 this same API duplicated all over your app 8 for each type of thing you want to import, in 7 other words.

This also lends itself very 6 easily to a background-task implementation. In 5 that case you probably want to add fields 4 to the individual task objects that allow 3 the API client to specify how they want 2 to be notified (a URL they want you to GET 1 when it's done, or send them an e-mail, etc.).

Yes, PUT creates/overwrites, but does not 2 partially update.

If you need partial update 1 semantics, use PATCH. See http://greenbytes.de/tech/webdav/draft-dusseault-http-patch-14.html.

You should use AtomPub. It is specifically designed 3 for managing collections via HTTP. There 2 might even be an implementation for your 1 language of choice.

For the POSTs, at least, it seems like you 4 should be able to POST to a list URL and 3 have the body of the request contain a list 2 of new resources instead of a single new 1 resource.

As far as I understand it, REST means REpresentational 18 State Transfer, so you should transfer the 17 state from client to server.

If that means 16 too much data going back and forth, perhaps 15 you need to change your representation. A 14 collectionChange structure would work, with 13 a series of deletions (by id) and additions 12 (with embedded full xml Representations), POSTed 11 to a handling interface URL. The interface 10 implementation can choose its own method 9 for deletions and additions server-side.

The 8 purest version would probably be to define 7 the items by URL, and the collection contain 6 a series of URLs. The new collection can 5 be PUT after changes by the client, followed 4 by a series of PUTs of the items being added, and 3 perhaps a series of deletions if you want 2 to actually remove the items from the server 1 rather than just remove them from that list.

You could introduce meta-representation 16 of existing collection elements that don't 15 need their entire state transfered, so in 14 some abstract code your update could look 13 like this:

{existing elements 1-100}
{new element foo with values "bar", "baz"}
{existing element 105}
{new element foobar with values "bar", "foo"}
{existing elements 110-200}

Adding (and modifying) elements 12 is done by defining their values, deleting 11 elements is done by not mentioning it the 10 new collection and reordering elements is 9 done by specifying the new order (if order 8 is stored at all).

This way you can easily 7 represent the entire new collection without 6 having to re-transmit the entire content. Using 5 a If-Unmodified-Since header makes sure that your idea of the 4 content indeed matches the servers idea 3 (so that you don't accidentally remove elements 2 that you simply didn't know about when the 1 request was submitted).

Best way is :

Pass Only Id Array of Deletable Objects from Front End Application To Web API
    2. Then You have Two Options: 
       2.1 Web API Way : Find All Collections/Entities using Id arrays and Delete in API , but you need to take care of Dependant entities like Foreign Key Relational Table Data too
     2.2. Database Way : Pass Ids to your database side, find all records in Foreign Key Tables and Primary Key Tables and Delete in same order i.e. F-Key Table records then P-Key Table records

0