4 ms·

A bit tangential to the Main post, however, taking a quick look at the so called "REST API" of Tesla: /vehicles/{id}/command/charge_port_door_open - Open the c

A bit tangential to the Main post, however, taking a quick look at the so called "REST API" of Tesla: /vehicles/{id}/command/charge_port_door_open - Open the charge port. /vehicles/{id}/command/charge_max_range - Set the charge mode to max range /vehicles/{id}/command/door_lock - lock doors These are all GET Methods. I am a bit surprised that the company that claims to pay so much attention to detail has used Blatantly incorrectly principles (Using Idempotent & Safe designated HTTP methods for actions that change the state of the Car) for their "REST" API.

georgemcbay 13y ago
Where does Tesla call it a "REST" API? AFAIK the API isn't even publicly documented (officially) and is only known because it was reverse engineered by sniffing traffic from the iOS and/or Android apps. The people who did that work refer to it as a "REST" API, but they aren't Tesla. As far as whether they should be using GET for these calls regardless of whether they call the API a "REST" one or not -- they are a pragmatic company, and the simpler the software is on an embedded device like a car the better; strict adherence to the intent of various http methods is less important than just keeping things as simple as possible, maybe they didn't even implement post or put, I doubt they are running apache on that thing.
- steveklabnik 13y ago
  It's not a matter of 'simple', it's a matter of correctness. GET being safe and idempotent is really important. For example, you get breakages like this: http://signalvnoise.com/archives2/google_web_accelerator_hey_not_so_fast_an_alert_for_web_app_designers.php http://signalvnoise.com/archives2/google_web_accelerator_hey... And hopefully, even on an embedded device, sending a POST as opposed to a GET should be trivial.
- cynicalkane 13y ago
  If they only have one method it should be POST. HTTP clients are free to retry GETs without warning the user or even without their direction.
  - Perseids 13y ago
    Do you know of any library that generates multiple GETs without some blatant warning in the documentation? I would guess that even though it might be allowed in the RFC it poses no problem in practice.
- jccooper 13y ago
  You're not calling those methods on the car. You're calling them on https://portal.vn.teslamotors.com/ https://portal.vn.teslamotors.com/ which has no particular limitations. Likely the web service communicates with the car over their VPN using an internal protocol (though it could well be similar, since there are web servers running in the car.) So there's no particular excuse based on "embedded systems". I do agree it should use POST, but it's not quite as bad as it looks. Besides it being an authenticated API (so bots aren't a real problem), the calls are almost all set up to create a certain state, and repeating that call once the car is in that state (or working on it, I presume) seems quite safe. 'auto_conditioning_start' and 'auto_conditioning_stop' are okay to repeat; 'auto_conditioning_toggle' not so much. Though one does kinda wonder about the horn honk one.

georgemcbay 13y ago

Where does Tesla call it a "REST" API? AFAIK the API isn't even publicly documented (officially) and is only known because it was reverse engineered by sniffing traffic from the iOS and/or Android apps. The people who did that work refer to it as a "REST" API, but they aren't Tesla. As far as whether they should be using GET for these calls regardless of whether they call the API a "REST" one or not -- they are a pragmatic company, and the simpler the software is on an embedded device like a car the better; strict adherence to the intent of various http methods is less important than just keeping things as simple as possible, maybe they didn't even implement post or put, I doubt they are running apache on that thing.

steveklabnik 13y ago
It's not a matter of 'simple', it's a matter of correctness. GET being safe and idempotent is really important. For example, you get breakages like this: http://signalvnoise.com/archives2/google_web_accelerator_hey_not_so_fast_an_alert_for_web_app_designers.php http://signalvnoise.com/archives2/google_web_accelerator_hey... And hopefully, even on an embedded device, sending a POST as opposed to a GET should be trivial.
cynicalkane 13y ago
If they only have one method it should be POST. HTTP clients are free to retry GETs without warning the user or even without their direction.
- Perseids 13y ago
  Do you know of any library that generates multiple GETs without some blatant warning in the documentation? I would guess that even though it might be allowed in the RFC it poses no problem in practice.
jccooper 13y ago
You're not calling those methods on the car. You're calling them on https://portal.vn.teslamotors.com/ https://portal.vn.teslamotors.com/ which has no particular limitations. Likely the web service communicates with the car over their VPN using an internal protocol (though it could well be similar, since there are web servers running in the car.) So there's no particular excuse based on "embedded systems". I do agree it should use POST, but it's not quite as bad as it looks. Besides it being an authenticated API (so bots aren't a real problem), the calls are almost all set up to create a certain state, and repeating that call once the car is in that state (or working on it, I presume) seems quite safe. 'auto_conditioning_start' and 'auto_conditioning_stop' are okay to repeat; 'auto_conditioning_toggle' not so much. Though one does kinda wonder about the horn honk one.