HTTP method to represent "fire and forget" actions in RESTful service

Question

Thinking about REST, it's relatively easy to map HTTP methods to CRUD actions: POST for create, GET for read, etc. But what about "fire and forget" actions? What HTTP method would best represent a fire and forget action such as triggering a batch job (in which no response is sent back to the caller)?

POST would spring to mind, but I think GET is a more appropriate method because 99% of the time you only supply a bunch of parameters to these types of actions. What do you think?

Answer 1

You should use POST if your request modifies data, and GET if it only reads it.

Since your request is "fire and forget", I guess that it's modifying data, so use POST.

Answer 2

I think in the general case we might well supply various payload parameters, and these plausibly might exceed what's possible with GET, so POST is quite reasonable - the action of starting a job doesn't to me fit well with GET sematics.

One thought, might not the action actually return a response:

a). No, sir, that's an impossible request we can't start your job. b). Understood, your job reference is 93.

Answer 3

POST would spring to mind, but I think GET is a more appropriate method because 99% of the time you only supply a bunch of parameters to these types of actions. What do you think?

External State

I think that the number of parameters you use has nothing to do with the verb you use. The key issue is are you changing externally visible state?

BatchJob Resources

In your example, if the batch job does not affect the externally visible state of any object then you could implement it as a batch job. However you could model your batch job as a resource with an associated resource container.

You could use a Post to create a new BatchJob resource and allow the user to do a GET to see the progress of the job so far. You could do a GET on the resource container to list all of the running batch jobs, possibly calling DELETE to kill one.

Answer 4

If you're concerned at that level, perhaps HEAD is the HTTP method you want; it's identical to GET, with the stipulation that the response body is empty. That sounds to me spot-on to what you're asking for?