7 ms·
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 lighti
by 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 agoI 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 agoIt 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 agoNothing about this alternative version is any more or less RESTful than the original version.
- Mandatum 11y agoGenerally 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 agoI 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 agoWhat 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.