6 ms·

ELI5 for a non-developer? I always thought it was just a way of sending commands or data to a sever. I created a RESTful (I think) service on a Raspberry Pi th

• steveklabnik 11y ago
  > ELI5 for a non-developer? There are multiple ways of putting multiple computers together. We call those ways "architectures." This guy named Fielding wrote a dissertation where he describes a number of different properties of different architectures. In chapter 5, he describes a particular set of properties, for a particular family of architectures, and calls them "REST". Years later, a whole ton of people misunderstand all this and call all sorts of other things REST. Confusion abounds.
• herge 11y ago
  REST is a series of principals used to structure APIs. Think about if you had a lot more lights on your Raspberry PI. A simple way would be having a call lighting up a specific light. But then the client must track state, in terme of rembering which lights are lit. In a REST sister, you'd request the state of all the lights (typically through a GET http request), which the server would track for you. Then you'd send back the lit or unlit state of all the lights, thereby setting a new state (typically, again, through an http POST request).
  • sokoloff 11y ago
    I don't see anything non-RESTy about your former example (and would argue it's a BETTER protocol design). Imagine we want to change the state of light 7 (and only light 7). A PUT/PATCH of "ON" "OFF" (or 1 or 0 or a float for a dimmer) to http://raspberry1.local/lights/7 http://raspberry1.local/lights/7 to change the status of light 7 is better IMO than doing a GET to http://raspberry1.local/lights http://raspberry1.local/lights and then a PUTS/PATCH to that same URL to update all lights status for the purpose of just updating one light. The latter is obviously fragile in the face of multiple writers (you'll lose updates on overlapping but not colliding writes-an update to light 6 that overlaps in time with light 7 can result in the earlier of those updates being lost when there's no inherent reason for it).
    • Mandatum 11y ago
      It really depends on the amount of calls you'll have to make. What if you had 10,000 lights? What we tend to do is allow for partial updates with PATCH on just the lights you'd want to change. ie PATCH http://bla/url/lights http://bla/url/lights { light1: ON, light351: ON, light 4672: ON } I think that since generally documentation around RESTful API's is generally very good with in-browser demo calls, interpretation of the REST API although differs between implementors, is generally relatively similar enough. However there are cases where REST design just won't work, or implementing the design abstracts work from the API supplier to the consumer. Where once a "runThisScript(object)" would be easy enough for a developer, now the script itself must be implemented by the developer to call the RESTful endpoints. In cases like this, we occasionally break REST design for the convenience of developers.
      • steveklabnik 11y ago
        Nothing about this alternative version is any more or less RESTful than the original version.
        • Mandatum 11y ago
          Generally HTTP REST works on the idea of resources and properties. so: /lights /lights/light-id /lights/light-id/wattage (return wattage of light) Doing something like: /lights/light-id/book-janitor-to-replace which might email and update the janitor's calendar/ToDo list, isn't really following the existing API design.
          • steveklabnik 11y ago
            I only bring this up because this is the topic of the article; that may be "REST as people talk about it" but none of that has anything to do with "what RESTful actually means".
          • gkop 11y ago
            What do you mean "following the existing API design"? A good API imo would hide the janitor's calendar/ToDo list unless it was absolutely necessary for the client to access it directly. Then an argument could be made in favor of the booking janitor endpoint on a light - and the API is no less RESTful. Edit: I don't like it when people over-emphasize resources when talking about REST. I blame this practice on Rails being many people's first introduction to REST. But Rails isn't actually RESTful per Fielding. I prefer to use the term resourceful API to describe the kind of API Rails prescribes. REST is generally in favor of custom endpoints that hide complexity from the client, even at the expense of having a clear cut decision on eg. POST vs PUT/PATCH for a given endpoint.