Does it violate REST principles for a REST API to support a batch of operations (perhaps with transactional guarantees) that can be added to a queue via a POST?

This design seems outside the scope of REST architecture but not necessarily in violation of it, but I'm looking for authoritative sources here, and/or supporting explanations when/why to avoid or prefer this approach.

For example, the Parse API supports a POST to create a batch of requests, each representing what could be a separate REST request, such as the following (quoting):

curl -X POST \
  -H "X-Parse-Application-Id: ${APPLICATION_ID}" \
  -H "X-Parse-REST-API-Key: ${REST_API_KEY}" \
  -H "Content-Type: application/json" \
  -d '{
        "requests": [
            "method": "PUT",
            "path": "/1/classes/GameScore/Ed1nuqPvcm",
            "body": {
              "score": 999999
            "method": "DELETE",
            "path": "/1/classes/GameScore/Cpl9lrueY5"
      }' \

1 Answer 1


From what I've read this does not violate REST. REST has to do with how the client and server communicate with each other; this communication has to be stateless, i.e. the client calls the server and the server responds, that's it, but that doesn't mean there isn't state involved. REST is also about being able to address resources, and resources have/are state.

One example I read (and I wish I could remember where so I could link it) was about transactions: you could do a POST to create a transaction resource, then do a series of PUTs to modify/update that transaction, then finally do a commit (I forget what HTTP verb this mapped to) to submit the transaction. All of these communications were RESTful (there was no communication channel state) but there was still state in/as the transaction resource.

Adding things to a processing queue en batch strikes me as being similar to the transaction example.

I've not done much REST stuff, but this seems OK to me.

Some somewhat related reading for interested parties

Your Answer

By clicking “Post Your Answer”, you agree to our terms of service and acknowledge you have read our privacy policy.

Not the answer you're looking for? Browse other questions tagged or ask your own question.