You may have a point that I didn't consider. So if we wanted to unlock the car, would we perhaps post new a version of the lock resource (in json, xml, or whatever serialization format the system uses), representing its new state, to the uri representing it?
Exactly. (except you would probably want to PUT the state instead of POST, since it's an idempotent operation)
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.
Thank you. That is very helpful. But what about if it was necessary to have one command that changed the state of more than one resource?
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?
> But what about if it was necessary to have one command that changed the state of more than one resource?
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.
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.