

Tesla Model S JSON API - daenz
http://docs.timdorr.apiary.io/?cmd=honk-horn

======
haberman
While this is clearly not REST-ful, the fact that the comments here can spend
so many words philosophizing over whether this _ought_ to be PUT vs. POST vs.
PATCH illustrates why REST is not my favorite technology.

It's like XML all over again. Should it be an attribute or a child node?
Should the parameter go in the header, or in the body, or in the URL? Should
it be part of the URL path, or a URL parameter? Should the error be indicated
in the HTTP status code or just in the body? Did we get it right, or do we
need to find a Roy Fielding quotation illustrating the principle we violated?

Normally this wouldn't bother me, since I generally have faith that the "free
market", so-to-speak, will favor the best technologies in the long run. But
HTTP and REST have an artificial boost in that they are the only way to get
through many firewalls, so in essence everyone has to go along with REST
whether they want to or not (or at least tunnel over it). And of course
everything _can_ be made to work with REST, so everyone eventually converges
on it, even if it's not the best fit, and its dominance grows.

~~~
zenocon
I (really do) hate posting this but I swear every single "REST" or "RESTful"
or "REST-ful" API post I see, there's always _that guy_ that chides it for not
being pure or _REST_ or "-ful" or something. Do we really care that much? Does
the API work? If so, move on...

~~~
Mandatum
If it doesn't follow the design pattern in some form that it states it does,
then it should be referred to as the technological interface it's offered
through - in this case a web service.

------
dlisboa
> This is unofficial documentation of the Tesla Model S REST API

Very few concepts have been so hugely corrupted to mean exactly the opposite
of what they mean as REST. This is probably the least REST API in existence.

~~~
gregory144
I agree with you, but I have trouble understanding the right way to implement
"commands" like this - I must be thinking about it in the wrong way. How would
you design a "real" REST interface for a command like this? What's the
advantage a "real" REST interface gives you in this case?

~~~
andrewstuart2
I don't know the whole state of the vehicle. I don't want to. So I'll use
PATCH. I know I want the horn to be in a honking state and remain in that
state for 1 second. The implementation is responsible for doing what it needs
to do in order to get the resource into the state (or differential state in
this case) I told it to take.

I'm not usually in favor of nested API design, but complex resources like cars
make sense, so:

PATCH /vehicles/{id}/horn { "enabled": true, "timeRemaining": 1000 }

~~~
SilasX
My initial thought would be that a request for a "honk action" is not
idempotent, so it should be a POST.

You could do it as a PUT or PATCH, but you'd have to do it differently from in
your example in order to preserve idempotence, due to the complications of
working with time.

Remember, if the request successfully goes through twice that should have the
same effect as if only the first succeeded. One way to accomplish that would
be to give an absolute start and end time for honk to be on. e.g.,

PUT /vehicles/{id}/horn { "enabled": true, "time_start":
"2014-04-12T20:12:36.1", "time_end": "2014-04-12T20:12:36.6"}

for a half-second honk.

------
noonespecial
Wait. GET's can unlock my doors and honk my horn and stuff? Don't let anything
spider that page of links!

~~~
waqf
Right, since it has side effects this should be a POST action.

~~~
noonespecial
I'd humbly submit that PUT is the better choice. POST is to create the
resource, PUT would be better to change its state. I don't want to make a new
horn, just honk the one thats there. (PUT is also usually considered
idempotent, honk as much as you want!)

    
    
      PUT /vehicles/{id}/horn
    
      {
      "command": "honk"
      }

~~~
pdonis
POST doesn't have to create a resource; it can also be used to annotate
existing resources.

The main problem with using PUT is that PUT is supposed to be idempotent; the
result of two PUTs with the same content should be the same as the result of a
single PUT with that content. But two PUTs to honk the horn would honk the
horn twice, not once.

Since we're all being pedantic about HTTP methods here, we should have a link
to RFC 2616 :)

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

~~~
noonespecial
Ahh. Good point. I was considering PUTting the horn into the honking state vs
POSTing horn honks for execution. In the first case, 2 PUT honks would just
result in a honking car, in the second, 2 POSTs would get you 2 "honks"
whatever those are defined to be.

I guess I was thinking of the idempotent "panic" button on my cars key fob.

~~~
pdonis
_the idempotent "panic" button on my cars key fob_

Hmmm, mine actually isn't--one hit turns panic mode on, the second turns it
off.

------
brianbarker
Let's talk bout the real reason this was posted: YOU CAN HONK THE HORN VIA A
REMOTE API!

------
mschuster91
If anyone ever manages to penetrate the central VPN server which Tesla uses
for its cars, this will be total mayhem.

Also, which server are they using? That alone is an interesting fact, as it
has to support tens of thousands of simultaneous connections...

~~~
greggman
Nothing special about Tesla

Many of the other car manufacturers provide remote access to cars. See GM's
OnStar, Ford's Sync Services, etc... One of those companies used to advertise
on TV you calling them and having them unlock your car remotely and IIRC
starting the engine.

~~~
userbinator
The difference is that those services are optional and often opt-in, whereas
with the Tesla it appears to be mandatory.

Personally, I'm not too fond of my car being accessible remotely unless it's
me who has control over that access.

~~~
mikeash
I doubt they're really opt-in, in the face of a hack. Having your car still
connect to the network means that they can activate a new account
instantaneously and without user intervention. It means they could potentially
sell non-subscribers on a car unlock right on the spot, rather than saying,
"tough luck, you should have subscribed to our service, after you get a
locksmith to unlock your door, call us back and we can help stop it from
happening again."

I would bet five Zimbabwe dollars that most systems of this type can be used
to control the cars of non-subscribers if taken over.

------
tshadwell
It's good to know that cars can now be remotely controlled via CSRF attacks.

------
stefan_kendall3
A company has an API FOR A CAR, and discussion devolves immediately into which
characters should be at the start of the HTTP request.

------
schoen
How do these commands get invoked, and how do the commands get delivered to
the individual cars? Is this something that people can invoke on the official
Tesla web site after authenticating to it in some way, or is it something that
people invoke on a web server running on their individual car?

~~~
bjt
The URL includes the car's ID number, strongly implying that this is a
centralized service running in a data center, not a server running on the
car's computer.

~~~
zoomerang
I can't wait for somebody to hack this and make every Tesla on the planet
start honking at the same time. (Presuming there's a 3G hookup of some kind
going on here)

------
matthuggins
Pretty sure this be a POST request.

------
daliwali
This API documentation has already been posted here twice today [1].

I remarked how non-RESTful this API is, which may have been the motivation for
the title of this submission [2].

[1]
[https://news.ycombinator.com/item?id=7961944](https://news.ycombinator.com/item?id=7961944)

[2]
[https://news.ycombinator.com/item?id=7962260](https://news.ycombinator.com/item?id=7962260)

------
nicklovescode
Other discussion on this topic here:
[https://news.ycombinator.com/item?id=7961944](https://news.ycombinator.com/item?id=7961944)

------
delinka
How _should_ one RESTify methods? If my 'state' is represented as objects, and
I want to execute a method on one of those [remote/server-side] object, what's
the RESTful way of calling that method? I don't even know what RPC over HTTP
should look like, let alone whether mixing it with REST would even be
acceptable.

~~~
marcosdumay
> let alone whether mixing it with REST would even be acceptable

Why wouldn't it be acceptable? Can you think about any reason? Because I
can't. (And you could reach some very nice API independence by carrying RPC
metadata at the REST API.)

The only thing I see here that I think is wrong is that the API uses GET when
it should use other verbs. But lots of people already pointed that.

------
sockgrant
Holy fucking pedantics, It's too bad people are focusing on REST.

This API makes me want to have a Tesla. There are so many interesting
apps/utilities that can be made with this!

------
zenocon
Hm.. wondering if:

/vehicles/{id}/snooplion/hydraulics/bounce

is idempotent or not?

------
giancarlostoro
Watch Dogs anyone?

------
nanavatiarpan
shouldn't this be a POST ?

------
notastartup
imagine if this was stuck on loop. hopefully some rate limiting is already
built in.

