14

I understand how to use REST for doing general entity interactions - using urls names to map to entities and the HTTP verbs to map to actions on those entities. But what is the generally accepted way of looking at "actions" more like RPC?

For example, let's say I want to send a command for the device to reset? There's no real "entity" here or do I do something like POST to http://mydevice/device/reset?

Marcus Leon
  • 55,199
  • 118
  • 297
  • 429
ctacke
  • 66,480
  • 18
  • 94
  • 155

3 Answers3

13

/device/reset or /system/reset are ok.

The REST "design pattern" does encourage you to NOT use any verbs.. You could do:

POST http://mydevice/system/state    
<stateType>RESET</stateType>

Related information:

Community
  • 1
  • 1
Marcus Leon
  • 55,199
  • 118
  • 297
  • 429
9

I don't think that's the case to use POST. The "RESET action" is a idempotent action (if you call it n times you will always get the same result), so IMHO you should use a PUT call instead POST (as POST is not idempotent).

Also, as you are Putting a resource, you can use

PUT http://system
<device>
  <status>RESET</status>
</device>

or

 PUT http://system/status/reset

But I think the first one is "more restful", since you are putting a resource, while the second one you just use the URL.

Diego Dias
  • 21,634
  • 6
  • 33
  • 36
  • so you'd say that PUT is an UPDATE and POST is an INSERT (IBM instead of Sun definition)? See this: http://stackoverflow.com/questions/2447677/rest-verbs-which-convention-is-correct/2447740#2447740 – ctacke Mar 15 '10 at 14:36
  • Not Really. If you think about CRUD, you can use this analogy, and it is correct to say that if you have an INSERT and an UPDATE, you should use POST and PUT, respectively. But the idempotence is more than that. Imagine there is a resource which you can only insert once on your DB and you should never change it. That's an insert and an idempotent action, so in this situation I think PUT would be used. – Diego Dias Mar 15 '10 at 14:44
  • 2
    PUT http://system/status/reset with an empty body just updates the resource to be empty. The first is the correct RESTful way. – Jan Algermissen Mar 15 '10 at 14:48
  • Also, differently from the link you posted. This use of PUT (idempotency and uploading a representation of a resource) is what the protocol of the Http methods say, not really a common use. http://en.wikipedia.org/wiki/Hypertext_Transfer_Protocol#Request_methods – Diego Dias Mar 15 '10 at 14:49
  • @Jan I agree with you. However as I don't know the exact use of the WS, I think that can also be used. – Diego Dias Mar 15 '10 at 14:51
  • But is reset really idempotent? If you reset a timer the second time, it leave you with a different situation, from if you had done it only the first time... (though the same as when you had only done it the second time) – Jasper Apr 28 '15 at 14:57
2

I usually name the entity "system" or something like that. So you do "/system/reset". You've chosen device so that works too.

But yea, I usually consider these types of actions to be updates, which would use the POST method. So I think you are right to POST to /device/reset

Seaux
  • 3,459
  • 2
  • 28
  • 27
  • Funny you should key in on the PUT/POST thing - I just asked about that as well: http://stackoverflow.com/questions/2447677/rest-verbs-which-convention-is-correct/2447714#2447714 – ctacke Mar 15 '10 at 14:19
  • I'll comment on that, but I also use a REST-variation as not all clients handle PUT/DELETE. Read the wikipedia page for REST: http://en.wikipedia.org/wiki/Representational_State_Transfer – Seaux Mar 15 '10 at 14:22
  • Yes, I read the Wikipedia article. Since I'm controlling both the service and the client end, I've got the luxury of using all 4 verbs. – ctacke Mar 15 '10 at 14:53