7 ms·

GET /vehicles/{id}/command/honk_horn Honk the horn once. HTTP aficionados, should this be a POST of a honk resource?

by zachrose 12y ago

pinko 12y ago
...or maybe even a PATCH of a horn resource, updating the value of "honking"?
- pfraze 12y ago
  Only if you plan for the horn to keep honking until you patch again, I figure. GET definitely should not produce a honking sound. GET is meant to not have side-effects. If the response to the GET were, say, a URL which refers to a usable honk (that could then be POSTed to) then it might sort of make sense. But, no, producing sound is i/o. This is bad design.
yock 12y ago
I wouldn't think so. The sound the horn makes is the requested resource. You're not creating anything new by requesting that sound.
- TeMPOraL 12y ago
  I disagree; you're creating a sound. If anything, it should probably be PUT and should return 201 Created on success. There are a lot of state-changing commands there that are all GET. This API is definitely not REST (i.e. just because it uses HTTP, doesn't make it RESTful).
  - nardi 12y ago
    Disagree with PUT. As stated above, this request is not idempotent (multiple requests result in multiple honks, not one), so it should be a POST (the only method intended for non-idempotent requests).
    - shawnz 12y ago
      Using a POST request would make sense in other ways, too. The endpoint could represent a timeline of all the honks that have occurred, and by POSTing to it you are creating a honk at the current time. On the other hand, PUT would make sense if you were specifying the time you wanted the honk to occur at as a parameter (and likewise that would be idempotent).
pfraze 12y ago
One good smell-test is to ask what would go wrong if you got spidered by Google. In this case (God help you) your horn would randomly honk. Thumbs down.
Aqueous 12y ago
I think it should probably be PUT or PATCH. POST is usually used to create a resource; PUT/PATCH is used to update, even if that update has an expiration (i.e. the horn stops honking.)
- deleted 12y ago
  [deleted]
- zachrose 12y ago
  Doesn't it depend on whether the resource is the horn that makes the sound or the sound itself?
- euphemize 12y ago
  PUT is idempotent, and also used to create new resources. I would use that rather than POST. [1][2] [1] http://stackoverflow.com/a/630475/443363 http://stackoverflow.com/a/630475/443363 [2] http://www.w3.org/Protocols/rfc2616/rfc2616-sec9.html http://www.w3.org/Protocols/rfc2616/rfc2616-sec9.html
  - zachrose 12y ago
    I'm curious how idempotence figures into something like this. If you make the same request twice, the horn should honk twice.
    - TheCoelacanth 12y ago
      > If you make the same request twice, the horn should honk twice. Exactly. That means this request is not idempotent, so PUT shouldn't be used. Of GET, PUT, POST and DELETE, only POST is not supposed to be idempotent, so it would be the preferred method to use for this request.
mikeash 12y ago
Looks like every HTTP method is supposed to be idempotent besides POST and CONNECT. With the latter making no sense here, that leaves POST.
deleted 12y ago
[deleted]
CCs 12y ago
It looks strange and not REST: GET /vehicles/{id}/command/set_charge_limit?percent={limit_value} Set the charge limit to a custom percentage.
- Mandatum 12y ago
  GET /vehicles/{id}/command/set_charge_limit?percent={limit_value} Set the charge limit to a custom percentage. Should be: POST or UPDATE /vehicles/{id}/settings/charge_limit Parameters: percent (int 0-100) Set the charge limit to a custom percentage. reply
alexdaukrainian 12y ago
The replies here make me sad. Two answers: 1) Honk is not a resource and using REST here makes no sense. When you want to send actions across network, RESTful HTTP is not as good of a technology as, say, Websockets. See http://blog.arungupta.me/2014/02/rest-vs-websocket-comparison-benchmarks/ http://blog.arungupta.me/2014/02/rest-vs-websocket-compariso... 2) If you must use RESTful HTTP, this would be a GET with an Authorization header that contains an authorization token. This solves the Google spider problem and, well, the fact that you don't want just anyone honking your horn! :)

GET /vehicles/{id}/command/honk_horn Honk the horn once. HTTP aficionados, should this be a POST of a honk resource?

pinko 12y ago

...or maybe even a PATCH of a horn resource, updating the value of "honking"?

pfraze 12y ago
Only if you plan for the horn to keep honking until you patch again, I figure. GET definitely should not produce a honking sound. GET is meant to not have side-effects. If the response to the GET were, say, a URL which refers to a usable honk (that could then be POSTed to) then it might sort of make sense. But, no, producing sound is i/o. This is bad design.

yock 12y ago

I wouldn't think so. The sound the horn makes is the requested resource. You're not creating anything new by requesting that sound.

TeMPOraL 12y ago
I disagree; you're creating a sound. If anything, it should probably be PUT and should return 201 Created on success. There are a lot of state-changing commands there that are all GET. This API is definitely not REST (i.e. just because it uses HTTP, doesn't make it RESTful).
- nardi 12y ago
  Disagree with PUT. As stated above, this request is not idempotent (multiple requests result in multiple honks, not one), so it should be a POST (the only method intended for non-idempotent requests).
  - shawnz 12y ago
    Using a POST request would make sense in other ways, too. The endpoint could represent a timeline of all the honks that have occurred, and by POSTing to it you are creating a honk at the current time. On the other hand, PUT would make sense if you were specifying the time you wanted the honk to occur at as a parameter (and likewise that would be idempotent).

pfraze 12y ago

One good smell-test is to ask what would go wrong if you got spidered by Google. In this case (God help you) your horn would randomly honk. Thumbs down.

Aqueous 12y ago

I think it should probably be PUT or PATCH. POST is usually used to create a resource; PUT/PATCH is used to update, even if that update has an expiration (i.e. the horn stops honking.)

deleted 12y ago
[deleted]
zachrose 12y ago
Doesn't it depend on whether the resource is the horn that makes the sound or the sound itself?
euphemize 12y ago
PUT is idempotent, and also used to create new resources. I would use that rather than POST. [1][2] [1] http://stackoverflow.com/a/630475/443363 http://stackoverflow.com/a/630475/443363 [2] http://www.w3.org/Protocols/rfc2616/rfc2616-sec9.html http://www.w3.org/Protocols/rfc2616/rfc2616-sec9.html
- zachrose 12y ago
  I'm curious how idempotence figures into something like this. If you make the same request twice, the horn should honk twice.
  - TheCoelacanth 12y ago
    > If you make the same request twice, the horn should honk twice. Exactly. That means this request is not idempotent, so PUT shouldn't be used. Of GET, PUT, POST and DELETE, only POST is not supposed to be idempotent, so it would be the preferred method to use for this request.

mikeash 12y ago

Looks like every HTTP method is supposed to be idempotent besides POST and CONNECT. With the latter making no sense here, that leaves POST.

deleted 12y ago

[deleted]

CCs 12y ago

It looks strange and not REST: GET /vehicles/{id}/command/set_charge_limit?percent={limit_value} Set the charge limit to a custom percentage.

Mandatum 12y ago
GET /vehicles/{id}/command/set_charge_limit?percent={limit_value} Set the charge limit to a custom percentage. Should be: POST or UPDATE /vehicles/{id}/settings/charge_limit Parameters: percent (int 0-100) Set the charge limit to a custom percentage. reply

alexdaukrainian 12y ago

The replies here make me sad. Two answers: 1) Honk is not a resource and using REST here makes no sense. When you want to send actions across network, RESTful HTTP is not as good of a technology as, say, Websockets. See http://blog.arungupta.me/2014/02/rest-vs-websocket-comparison-benchmarks/ http://blog.arungupta.me/2014/02/rest-vs-websocket-compariso... 2) If you must use RESTful HTTP, this would be a GET with an Authorization header that contains an authorization token. This solves the Google spider problem and, well, the fact that you don't want just anyone honking your horn! :)