4 ms·
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
by 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 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.