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 also an appropriate method because 99% of the time you only supply a bunch of parameters to these types of actions. What do you think?

Propitiate

Answer 1

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.

Vaginismus

Answer 2

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.

Hema

It's reading data from one system and writing it to another system – Propitiate

But it's still writing, right? The point is, use GET only if you don't change anything. – Hema

No, you can use whatever you want if the externally visible state hasn't changed. If you are looking for side-effect free REST then any system that logs to the filesystem isn't RESTful. – Vaginismus

Answer 3

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.

Transfigure

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?

Lavina

Answer 5

I'm bringing this question back from the dead to offer a different point of view.

Now that CORS is prevalent, the choice between using GET or POST becomes a matter of if you want anyone who knows your API URI to be able to trigger the batch job (GET), or if you want to restrict the origin of the request to prevent any Joe with a computer from triggering the job (POST).

Stricker