json - REST: Updating Multiple Resources With One Request - Is it standard or to be avoided? -

a simple rest api:

• get: items/{id} - returns description of item given id
• put: items/{id} - updates or creates item given id
• delete: items/{id} - deletes item given id

now api-extension in question:

• get: items?filter - returns item ids matching filter
• put: items - updates or creates set of items described json payload
• [[delete: items - deletes list of items described json payload]] <- not correct

i being interested in delete , put operation recycling functionality can accessed put/delete items/{id}.

question: common provide api this?

alternative: in age of single connection multiple requests issuing multiple requests cheap , work more atomic since change either succeeds or fails in age of nosql database change in list might have happend if request processing dies internal server or whatever due whatever reason.

[update]

after considering white house web standards , wikipedia: rest examples following example api purposed:

a simple rest api:

• get: items/{id} - returns description of item given id
• put: items/{id} - updates or creates item given id
• delete: items/{id} - deletes item given id

top-resource api:

• get: items?filter - returns item ids matching filter
• post: items - updates or creates set of items described json payload

put , delete on /items not supported , forbidden.

using post seems trick being 1 create new items in enclosing resource while not replacing appending.

http semantics post reads:

extending database through append operation

where put methods require replace complete collection in order return equivalent representation quoted http semantics put:

a successful put of given representation suggest subsequent on same target resource result in equivalent representation being returned in 200 (ok) response.

[update2]

an alternative seems more consistent update aspect of multiple objects seems patch method. difference between put , patch described in draft rfc 5789 being:

the difference between put , patch requests reflected in way server processes enclosed entity modify resource identified request-uri. in put request, enclosed entity considered modified version of resource stored on origin server, , client requesting stored version replaced. patch, however, enclosed entity contains set of instructions describing how resource residing on origin server should modified produce new version. patch method affects resource identified request-uri, , may have side effects on other resources; i.e., new resources may created, or existing ones modified, application of patch.

so compared post, patch may better idea since patch allows update post allows appending meaning adding without chance of modification.

so post seems wrong here , need change our proposed api to:

a simple rest api:

• get: items/{id} - returns description of item given id
• put: items/{id} - updates or creates item given id
• delete: items/{id} - deletes item given id

top-resource api:

• get: items?filter - returns item ids matching filter
• post: items - creates 1 or more items described json payload
• patch: items - creates or updates 1 or more items described json payload

you patch collection, e.g.

patch /items [ { id: 1, name: 'foo' }, { id: 2, name: 'bar' } ] 

technically patch identify record in url (ie patch /items/1 , not in request body, seems pragmatic solution.

to support deleting, creating, , updating in single call, that's not supported standard rest conventions. 1 possibility special "batch" service lets assemble calls together:

post /batch [   { method: 'post', path: '/items', body: { title: 'foo' } },   { method: 'delete', path: '/items/bar' } ] 

which returns response status codes each embedded requests:

[ 200, 403 ] 

not standard, i've done , works.