I believe that another correct way to approach this would be to create another resource that represents your collection of resources.
Example, imagine that we have an endpoint like /api/sheep/{id}
and we can POST to /api/sheep
to create a sheep resource.
Now, if we want to support bulk creation, we should consider a new flock resource at /api/flock
(or /api/<your-resource>-collection
if you lack a better meaningful name). Remember that resources don't need to map to your database or app models. This is a common misconception.
Resources are a higher level representation, unrelated with your data. Operating on a resource can have significant side effects, like firing an alert to a user, updating other related data, initiating a long lived process, etc. For example, we could map a file system or even the unix ps
command as a REST API.
I think it is safe to assume that operating a resource may also mean to create several other entities as a side effect.
与恶龙缠斗过久,自身亦成为恶龙;凝视深渊过久,深渊将回以凝视…