5 ms·

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 j

• mixedbit 14y ago
  Agree, there is a long way from HTTP API to REST API and this one is definitely missing key REST features.
• timdorr 14y ago
  True. It's not truely RESTful, just REST-ish. But if you wanted to wrap this in an HTTParty or RestClient library, that would still work.
• addlepate 14y ago
  Gee, I never hear that every single time the word "RESTful" is uttered.
• sopooneo 14y ago
  I agree. This interface is not RESTful, and that's good, because it's not a good fit for REST. I may be wrong, but it seems REST is best suited for accessing and creating resources. And it seems you would have to do a lot of conceptual mashing to represent all this API needs to do as resources. I am happy to be corrected.
  • prawks 14y ago
    For more topics along these lines, look into Resource-oriented Architecture (ROA) [1]. Many REST tutorials and classes are often further labeled as Service-oriented, which is really untrue. This is also why many existing SOAs are unfit for a RESTful transformation. Truly RESTful API's deal with resources, not services/business processes. [1] http://en.wikipedia.org/wiki/Resource-oriented_architecture http://en.wikipedia.org/wiki/Resource-oriented_architecture
  • bct 14y ago
    What "conceptual mashing" is required? Your resources are things like locks, batteries and thermostats. It seems pretty straightforward to me.
    • sopooneo 14y ago
      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? Exampe: POST {"state": "unlocked} to http://doors/front-left/lock http://doors/front-left/lock I realize I don't understand this, so your comment, and any further points you have, are sincerely appreciated.
      • bct 14y ago
        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.
        • sopooneo 14y ago
          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?
          • bct 14y ago
            > 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.
• ceslami 14y ago
  Beau, everyone certainly agrees with you. This same comment appears any time someone mentions REST. The phrase has indeed been repurposed to describe HTTP APIs, generally, despite the hard work of Fielding to give REST a proper meaning. It would be better if people just said "HTTP" when they mean "REST," but that's a long shot.