5 ms·
Tesla Model S JSON API
- noonespecial 12y agoWait. GET's can unlock my doors and honk my horn and stuff? Don't let anything spider that page of links!
- eknkc 12y agoWorks with a cookie though. Still, I'm gonna bet that someone's gonna find a way to abuse this in a hillarious way.
- noonespecial 12y agoI think its worse than that. This invites accidental hilarious fails much more.
- waqf 12y agoRight, since it has side effects this should be a POST action.
- grinich 12y agoor a PUT rather ;P
- noonespecial 12y agoI'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 12y agoPOST 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 12y agoAhh. 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.
- deleted 12y ago[deleted]
- daurnimator 12y agoActually it's 7231 now ;) http://tools.ietf.org/html/rfc7231#section-4 http://tools.ietf.org/html/rfc7231#section-4
- randallsquared 12y agoPOST is for anything that isn't actually CRUD, too. http://tools.ietf.org/html/draft-ietf-httpbis-p2-semantics-16#section-7.5 http://tools.ietf.org/html/draft-ietf-httpbis-p2-semantics-1... PUT can be creation (not only POST), if you know the URI of the resource in question, but PUT implies that the submitted data should create or replace the resource at that URI, and in the case of a physical horn, this is impossible. I don't think you should ever be able to PUT to something that it's impossible, even in theory, to create with a PUT.
- deleted 12y ago[deleted]
- jholman 12y agoI humbly submit that using PUT is wrong. Argument follows, citing wording at http://www.w3.org/Protocols/rfc2616/rfc2616-sec9.html http://www.w3.org/Protocols/rfc2616/rfc2616-sec9.html First of all, we're not "enclosing" an "entity" to be "stored" or "accepted", so neither HTTP verb is strictly appropriate. PUT requests are for uploading a resource, and the uploader specifies the desired final URL. So PUT is only appropriate for creating a new horn. Relevant quotation: In contrast [with POST], the URI in a PUT request identifies the entity enclosed with the request -- the user agent knows what URI is intended and the server MUST NOT attempt to apply the request to some other resource. If the server desires that the request be applied to a different URI, it MUST send a 301 (Moved Permanently) response; the user agent MAY then make its own decision regarding whether or not to redirect the request. POST requests, by contrast, are sent to a handling resource, which decides what to do. POST is appropriate for several purposes, including "annotating existing resources" and "providing ... data ... to a data-handling process". Seems like a better fit. But either way, REST is for documents (understood broadly), and I don't think I know how to understand "document" broadly enough to cover a horn. So it's gonna be a rough stretch, and in general, I'm skeptical about the value of applying REST semantics.
- sambe 12y agoDoesn't it depend on the level of abstraction you see? The URI of the horn is known. The document is { remainingDuration: 1 }.
- noonespecial 12y ago>But either way, REST is for documents (understood broadly), and I don't think I know how to understand "document" broadly enough to cover a horn. So it's gonna be a rough stretch, and in general, I'm skeptical about the value of applying REST semantics. That's probably about the wisest thing that's going to be posted on the subject tonight. I did a large enunciator panel project and we ended up being "rest-ish", using the idempotent PUT to put hardware dodads into various states, and reserving POST for adding things to execution queues. Being clear and consistent is probably the silver pearl in any implementation. Hardware control always degrades to some kind of RPC scheme, even if you dress it in a REST outfit.
- madeofpalk 12y agoYou don't want to make a new horn, but you want to make a new 'honk'
- notastartup 12y agoimagine if this was stuck on loop. hopefully some rate limiting is already built in.
- giancarlostoro 12y agoWatch Dogs anyone?
- matthuggins 12y agoPretty sure this be a POST request.
- deleted 12y ago[deleted]
- schoen 12y agoHow 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 12y agoThe 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 12y agoI 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)
- nicklovescode 12y agoOther discussion on this topic here: https://news.ycombinator.com/item?id=7961944 https://news.ycombinator.com/item?id=7961944
- dlisboa 12y ago> 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 12y agoI 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?
- benregenspan 12y agoExactly -- where does something that is designed for "state transfer" get you when the goal is to only temporarily modify a state/send a command that modifies internal state for X amount of time, not really "transfer" one at all? REST maps very nicely to CRUD operations, but not to this.
- zachrose 12y agoSure, but maybe you could think of POSTing to /honks as "creating a honk." This would make sense if you wanted to GET /honks and see a collection of previous honks. (Modifying an existing honk doesn't make sense, so we wouldn't have to worry about it.)
- andrewstuart2 12y agoI wouldn't mind performing GET /vehicle/{id}/honks?since={time}&limit=1000 to see an indicator of how aggressively my car has been driven. Especially if somebody else is driving it.
- shawnz 12y agoI think this interpretation is the best fit. Similarly PUT would be appropriate for requests where you are specifying the time that the honk should occur, which would make them idempotent.
- deleted 12y ago[deleted]
- deleted 12y ago[deleted]
- mschuster91 12y agoIf 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 12y agoNothing 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 12y agoThe 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 12y agoI 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.
- timdorr 12y agoThe app server was Thin last I checked. It's a Ruby app, though probably not Rails (hopefully not, at least). The streaming stuff is a node.js server. I assume they have a load balancer in front of it all. Keep in mind this isn't for the telematics, which are an entirely different system. This just gives you a view into some parts of that system. This is primarily used by the mobile apps, so the activity level is likely much lower than that.
- nanavatiarpan 12y agoshouldn't this be a POST ?
- tshadwell 12y agoIt's good to know that cars can now be remotely controlled via CSRF attacks.
- delinka 12y agoHow 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 12y ago> 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.
- haberman 12y agoWhile 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.
- philwelch 12y agoSometimes you just need to call a procedure, remotely.
- andrewchoi 12y agoIsn't that what SOAP is for?
- zachrose 12y agoIf HTTP is a bad fit for RPC interfaces, is there something that is a better fit?
- brianbarker 12y agoLet's talk bout the real reason this was posted: YOU CAN HONK THE HORN VIA A REMOTE API!
- daliwali 12y agoThis 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
- zenocon 12y agoHm.. wondering if: /vehicles/{id}/snooplion/hydraulics/bounce is idempotent or not?
- sockgrant 12y agoHoly 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!
- stefan_kendall3 12y agoA company has an API FOR A CAR, and discussion devolves immediately into which characters should be at the start of the HTTP request.