Hacker News new | past | comments | ask | show | jobs | submit login

There are some ways, I'm just thinking off the top of my head for one here.

If the resources of the car were mapped and had states it could work fine with a full REST interface. You could change the state of the horn like you change the state of a switch. You'd change the horn to be "on", not call some "turn it on" procedure.

They have some indications of that. There's a URL that returns the state of the vehicle (driving and position). That's something that could be mapped as a first-class citizen and someone could mess with it with the semantics of the verbs.

Commands are a much more RPC area though, REST doesn't map perfectly. You can almost always make a command into something of a resource state change, it just isn't always simpler. REST wouldn't give them much in this case as it's hard to imagine they'd make use of any of REST advantages. Not that there wouldn't be any technically (being able to evolve APIs without breaking clients is a pretty big advantage, plus plenty of other things), but that for their business it doesn't matter (they control every client).




You change the state of the horn to be on, but I'd imagine you might want the horn to automatically sound for a predefined length of time. Then the mapping is less obvious. Agreed that it doesn't really matter much in Tesla's case anyway.


You're still changing its state. If you have one horn you can do whatever you want with it, just like a normal person would. What the client does with a resource is only limited by the API, REST doesn't care what the messages contain. The semantic of the message is up to the API to resolve, you could encode that "stay on for 10 seconds" however you wanted.




Guidelines | FAQ | Lists | API | Security | Legal | Apply to YC | Contact

Search: