We're looking at creating a web services/REST API layer that will be consumed by web and mobile clients.

To make the solution more robust I was considering putting the commands from PUT, POST, and PATCH onto a message queue, which would mean that they would then be executed asynchronously.

Is there a standard HTTP response from a RESTful API that indicates that a command will be executed asynchronously?


Actually, if anyone had any thoughts on how sensible it is to have a message queue behind a web services layer I'd be interested to hear them.

  • I'm just wondering how this makes it more robust. Will these operations be taking a long time to execute? Is there not a way to give the caller a meaningful response and status code right away?
    – MetaFight
    Apr 16, 2015 at 10:40
  • No, the operations shouldn't take particularly long to execute. I guess I could return a "202" (accepted) response. Apr 16, 2015 at 11:07
  • Then why process then asynchronously?
    – MetaFight
    Apr 16, 2015 at 11:09
  • @MetaFight - async allows you to queue messages, to deal with load spikes, system failures, etc.
    – paj28
    Apr 16, 2015 at 13:40
  • I think you should be dealing with load spikes outside of the application code. Load balancing and redundancy is more of an infrastructure concern.
    – MetaFight
    Apr 16, 2015 at 13:46

3 Answers 3


The successful creation of the task to do whatever was successful. This means that one should be looking in the 2xx block of the response codes.

In this block one jumps out as the correct answer quite quickly:

202 Accepted
The request has been accepted for processing, but the processing has not been completed. The request might or might not eventually be acted upon, as it might be disallowed when processing actually takes place.

You may also wish to look at the 201 response for situations where the resource (the task) has been created, and you just want to say that.

201 Created
The request has been fulfilled and resulted in a new resource being created.

This, however does not imply the asynchronous nature of the interaction and instead implies that it is there, somewhere.


You miss the opportunity to report errors that may occur while processing the message. That way the consumer of your service can never be sure if the call was successful.

  • This is more of a comment than an actual answer, but I agree with you.
    – MetaFight
    Apr 16, 2015 at 13:49
  • Good point. That is definitely a downside to my initial idea. Apr 21, 2015 at 11:25

Use 200 Ok

The setup you propose is common with a service orientated architecture (SOA). When using asynchronous messaging you typically have a flow like:

--> Request
<-- Delivery acknowledgement
<-- Process acknowledgement
--> Delivery acknowledgement

It is typical to use 200 Ok for a successful delivery acknowledgement. I would expect this to be widely documented online, although I just had a quick look for a reference and couldn't find one.

The process acknowledgement is a separate HTTP transaction, in the reverse direction, and this allows you to report any errors during processing.

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.