3 ms·

The practical problem I have seen with systems (mis?)designed like this is a scenario when the client needs to do action X on resource Y attached to thingy Z -

The practical problem I have seen with systems (mis?)designed like this is a scenario when the client needs to do action X on resource Y attached to thingy Z - and they already have all the required info to do that action - then they still need to do a request on Z to get the URL for Y and do a request on Y to get the url for action X, which adds extra requests and latency for no good reason. Like, there's no significant difference if there is some original request that has been made, but often that "original" request is otherwise unnecessary and only gets made to enable that extra layer of indirection.

dragonwriter 5y ago
> The practical problem I have seen with systems (mis?)designed like this is a scenario when the client needs to do action X on resource Y attached to thingy Z - and they already have all the required info to do that action - then they still need to do a request on Z to get the URL for Y and do a request on Y to get the url for action X, which adds extra requests and latency for no good reason. If they have “all the info they need”, they have the identity of Y, which in a system designed around REST is the URL, and if Y is a resource, then its URL is the URL for actions on it, and the type of thing it is will tell you what method to use and (where one is applicable) resource to send to accomplish the action. HATEOAS is more than just shipping URLs.