5 ms·
Tesla Model S REST API
- zachrose 12y agoGET /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 agoOnly 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 agoI 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 agoI 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 agoDisagree 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 agoUsing 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 agoOne 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 agoI 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 agoDoesn't it depend on whether the resource is the horn that makes the sound or the sound itself?
- euphemize 12y agoPUT 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 agoI'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 agoLooks 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 agoIt 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 agoGET /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 agoThe 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! :)
- spullara 12y agoThis has been around for a long time. I've been tracking all the data accessible in the REST API since I got my car in February of last year. https://github.com/spullara/teslalogger https://github.com/spullara/teslalogger
- stephenitis 12y agoAre there optional parameters with these endpoints?
- daliwali 12y agoThis more closely resembles a RPC (Remote Procedure Call) API, rather than adhering to REST principles. For example, making GET requests should only retrieve data and not mutate state, whereas in this API, there's GET requests to honk the horn, unlock and lock doors, setting AC temperature, etc. Query parameters in the URL are also misused to pass information to be saved on the server. Stop labelling every API that operates over HTTP as a REST API, this one clearly isn't.
- qhoc 12y agoDoes anyone know or have a workable app using Tesla API? Or is it pretty much documentation at this point? Because I have seen various versions of the doc all over the internet.
- sahaskatta 12y agoMy app: http://glasstesla.com http://glasstesla.com
- qhoc 12y agoDon't mean to insult but is it "working"?
- sahaskatta 12y agoOf course, 300+ people using regularly!