Tesla Model S REST API | Hacker News Reader

Tesla Model S REST API

docs.timdorr.apiary.io

47 pointsdavidbarker23 comments

  GET /vehicles/{id}/command/honk_horn

  Honk the horn once.

HTTP aficionados, should this be a POST of a honk resource?

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.

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-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! :)

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.)

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

[2] http://www.w3.org/Protocols/rfc2616/rfc2616-sec9.html

I'm curious how idempotence figures into something like this. If you make the same request twice, the horn should honk twice.

> 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.

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

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).

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).

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).

It looks strange and not REST:

    GET /vehicles/{id}/command/set_charge_limit?percent={limit_value}

    Set the charge limit to a custom percentage.

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.

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

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.

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

This 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.

This 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

Does 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.

My app: http://glasstesla.com

Don't mean to insult but is it "working"?

Of course, 300+ people using regularly!

Are there optional parameters with these endpoints?

Reply on news.ycombinator.com