1

Let's say I have a REST interface with a resource called Jobs which have Properties. I'd have an interface that looks like this:

GET|POST|PUT|DELETE /jobs/:id
GET|POST|PUT|DELETE /jobs/:jobId/properties/:id

Now, let's assume that I want to execute that I want to execute that job. Executions aren't really resources. They are essentially commands that you want to tell the server to act upon Jobs.

What is the best interface from a REST perspective to do this? Options I have come up with:

PUT /jobs/:id/execute
PUT /jobs/execute/:id
PUT /commands/execute_job/:jobId
POST /jobs/:id/executions

But I don't know which is best. ALSO, I don't know if PUT is correct. I am suggesting PUT because the execute command will ultimately modify some of the data on the Job resource. My last option would turn execute into a resource, like I am creating a new execution, but that doesn't feel right because it is not like I am going to have GET/PUT/DELETE verbs on it.

What is the REST way to do this?

Brian Genisio
  • 47,787
  • 16
  • 124
  • 167
  • 4
    Anything that works well for you is just fine, don't overdo it with trying to get the theoretical semantics "perfectly" right. FWIW I 'd probably use `POST /jobs/:id/execute` -- you are "adding" an execution to the job. – Jon Jun 11 '13 at 19:10
  • 1
    Definitely not a `PUT`, as it is an idempotent method. You say your last option would be turning `execute` into a resource, but your last option just created one (a "resource" is just a "thing"). If you don't want to allow GET/PUT/DELETE to it, it's ok, that what `OPTIONS` and `405 - Method Not Allowed` are for. Anyway, I just did a - maybe very long :( - answer about the subject, so it may help: http://stackoverflow.com/questions/16877968/call-a-server-side-method-on-a-resource-in-a-restful-way/16878494#16878494 If you still wanna discuss the subject, then I'll be glad to join. – acdcjunior Jun 13 '13 at 03:00
  • Whoa, @acdcjunior, that WAS a long post... but it was full of useful info. Thanks! – Brian Genisio Jun 13 '13 at 12:46
  • 1
    About your answer, it is a good (if not the best, but one can always argue against that) solution considering execute is a synchronous task (otherwise a `execution/:id` would also be necessary for the tracking of each task). Just don't bet too much on that DOCUMENT/COLLECTION/STORE/CONTROLLER classification (used in a "tool(?)" known as WRML), there are lots of controversies about it. – acdcjunior Jun 13 '13 at 14:08

1 Answers1

0

I've done some research, and I found that what I am referring to is a REST controller (from the DOCUMENT, COLLECTION, STORE, CONTROLLER) classification.

In this case, @Jon is correct. The best representation of my command would be:

POST /jobs/:id/execute
Brian Genisio
  • 47,787
  • 16
  • 124
  • 167