Does Tesla describe it as a RESTful API, though? By the looks of things, the author has discovered it and decided to call it RESTful himself, even though it's just an HTTP API.
A RESTful API is more than just using GET to access resources.
A RESTful API is more than just using GET to access resources.
It would be better if people just said "HTTP" when they mean "REST," but that's a long shot.
[1] http://en.wikipedia.org/wiki/Resource-oriented_architecture
Exampe: POST {"state": "unlocked} to http://doors/front-left/lock
I realize I don't understand this, so your comment, and any further points you have, are sincerely appreciated.
You would GET the lock to see if it's locked, GET the battery to read its charging state.
You could PUT to the battery (or to some more abstract, finer-grained resources) to set the charge mode and turn charging on and off. The HVAC and thermostat would work the same way.
The only tricky stuff is "flash lights" and "honk horn"; they're inherently commands, so you might as well implement them in the RPC style that Tesla has used. They can't benefit from anything REST has to offer anyways.
And as you say, since certain aspects of the API (like honk horn) are unfit for REST, does it make sense to have the other parts of the API in REST? And then you've have two API's at once?
Then you need to have another resource that encompasses the aspects that need to be changed. Sometimes resources have to be somewhat abstract.
> since certain aspects of the API (like honk horn) are unfit for REST, does it make sense to have the other parts of the API in REST?
If the application benefits from the constraints that REST provides then why wouldn't it make sense? It's still one API, "honk" and "flash" don't need to be walled off from the other elements of the API in any way.