You would be better off using a non-positional identifier such as a UUID for collection items, to avoid problems such as the url of an item changing when you delete an item that precedes it. (Of course, you can still use itemN or just N, as long as the number stays attached to the same item at all times, leaving gaps after deletions, but a UUID is less confusing.)
The collection has the url /service/items/. Each item has the url /service/items/<id>.
- Creating items and collections is a POST on the parent of the resource.
- You could use a PUT if the client has the right and ability to generate the name or id of the resource.
- Removing items and collections is a DELETE on the resource itself.
- Adding multiple items is either multiple POST or a multi-item POST on the parent (the collection).
- Removing multiple items is a DELETE on each resource. I would discourage multi-item DELETE for two reasons:
- Bulk deletion is a dangerous operation (for which reason, I would also discourage DELETE on a non-empty collection).
- The only meaningful target of the operation is the parent collection, thus making bulk DELETE asymmetric with respect to single-item DELETE.
If you really need bulk deletion capability, provide it through a different, clearly marked API, such as PURGE /service/items.