5 ms·

> is a good way for a server to expose data to an intelligent human-guided client (i.e. a web browser) A web-browser doesn't have any concept of REST; it only

> is a good way for a server to expose data to an intelligent human-guided client (i.e. a web browser) A web-browser doesn't have any concept of REST; it only provides a sandbox for the client code which knows how to map paths to data (but pretty much never does so by means of any sort of introspection). Note that this isn't advocating against REST or in favor of RPC, just a neutral observation.

deleted 8y ago
[deleted]
munk-a 8y ago
Actually the original, core, really REST thing (that almost no one views as REST anymore) is all about resource exposure, and a dumb browser doesn't know how to interact with it but a REST aware generic browser could potentially interact with RESTful endpoints without other assistance. I'm specifically talking about the portion of rest that includes delivering actions with noun results, i.e. "Here's you comment record, if you want to edit it go to this URL, if you want to delete it here's a different one". Also, I, personally, find that portion of REST to be silly. I like the organizational hints and guidelines, but the resource discovery seems far too pipe-dreamy to ever be built on a large scale.
- philwelch 8y ago
  > I'm specifically talking about the portion of rest that includes delivering actions with noun results, i.e. "Here's you comment record, if you want to edit it go to this URL, if you want to delete it here's a different one". How does that not describe a normal HTML page that has "edit" and "delete" links right next to the newly-created comment that it displays to you after you click the "reply" button on Hacker News? I mean, it's not automatic discovery, because you're relying on a human being to read a rendered web page and know what the links mean, but it kind of qualifies if you expect that the client is partially made of meat.
  - munk-a 8y ago
    That's sort of the point, it was to remove the meat requirement on discovering those. Making the edit/delete/whatever forms and requirements machine readable so a stronger but still generic client tool can interpret them more intelligently. Again, I think it's naive since while a lot of stuff has plain CRUD operations, there are entities in most webapps that have more complex operations. If I were writing an application that partially managed cutlery in a restaurant it's not clear where a "clean" verb on a fork would fit into REST and how a generic client would understand what significance "clean" has especially as it relates to future eat actions. I have read through and understand the intent of the original RESTful system and I think there are some good and bad points. But, automatic discovery was definitely included in their vision of how it'd work, and actually seems like the center point TBH.
    - philwelch 8y ago
      > That's sort of the point, it was to remove the meat requirement on discovering those. Making the edit/delete/whatever forms and requirements machine readable so a stronger but still generic client tool can interpret them more intelligently. Hmm, that makes REST sound like it's pursuing similar ideas as the Semantic Web. > Again, I think it's naive since while a lot of stuff has plain CRUD operations, there are entities in most webapps that have more complex operations. If I were writing an application that partially managed cutlery in a restaurant it's not clear where a "clean" verb on a fork would fit into REST and how a generic client would understand what significance "clean" has especially as it relates to future eat actions. It isn't clear at all. It's possible, but in weird, hacky ways. Maybe when you're done with a fork, you DELETE the fork and then you can POST to /clean_forks/ to create a newly cleaned fork. And if you run out of forks to clean, it throws a 503 error. It's a terrible Kingdom of Nouns (https://steve-yegge.blogspot.com/2006/03/execution-in-kingdom-of-nouns.html https://steve-yegge.blogspot.com/2006/03/execution-in-kingdo...) but it might appeal to some people, for the same reasons that the original Kingdom of Nouns appealed to some people. After all, you get to feel clever and smart when you invent new design patterns to work around the limitations of your technology. Just writing a `clean_fork` RPC doesn't make you feel clever at all. In any case, while I can see automatic discovery as a useful feature for web browsers (who can still punt the actual decision-making to the meat, as long as they know what the plausible next steps would be), it doesn't seem likely to me that service clients would benefit from it any more than they benefit from a thoughtfully designed and documented RPC API. Meanwhile, for whatever reason, the end-user-facing web has decided to prioritize the use case of, "you will see and interact this web page according to The Original Creative Intention Of The Author" over the use case of, "here, have some data, it links together, do whatever the hell you want with it, I don't care what fonts or UI widgets you use". REST would have been great for the second use case; it's just that nobody cares about it anymore.
- dsego 8y ago
  I thought the general idea is to code the client against a well defined and sanctioned media type. If the media type returns items and actions, a well coded client should be able to handle it (whether it is to show it as GUI and provide controls or do some automated response etc). The point of returning actions is that URLs change, and must be able to change. Instead of following HATEOAS guidelines, people hardcode routes and lament about how URLs should be structured (flat vs nested, e.g. `/posts/1/commment/4` vs `/comments/4`) and then they also have to be versioned etc. (`api/v2/posts`). Now that is silly.
  - philwelch 8y ago
    > If the media type returns items and actions, a well coded client should be able to handle it (whether it is to show it as GUI and provide controls or do some automated response etc). In a web service context, is there a HATEOAS web client library that I can use to make service calls without having to specify endpoints and request formats ahead of time? > Instead of following HATEOAS guidelines, people hardcode routes...and then they also have to be versioned etc. (`api/v2/posts`). In the web service use case, it's considerably simpler to define and specify a set number of endpoints ahead of time, define request and response formats, document that specification in OpenAPI, and use versioning if the API itself changes. This isn't RESTful. It's just RPC over HTTP. But it works and it's not "silly".
- geezerjay 8y ago
  > Also, I, personally, find that portion of REST to be silly. I like the organizational hints and guidelines, but the resource discovery seems far too pipe-dreamy to ever be built on a large scale. The amount of work really isn't that great when compared with having to layout routes. Proper HATEOAS is like unit testing: people complain it takes too much work but then complain that the lack of tests is a problem.

deleted 8y ago

[deleted]

munk-a 8y ago

Actually the original, core, really REST thing (that almost no one views as REST anymore) is all about resource exposure, and a dumb browser doesn't know how to interact with it but a REST aware generic browser could potentially interact with RESTful endpoints without other assistance. I'm specifically talking about the portion of rest that includes delivering actions with noun results, i.e. "Here's you comment record, if you want to edit it go to this URL, if you want to delete it here's a different one". Also, I, personally, find that portion of REST to be silly. I like the organizational hints and guidelines, but the resource discovery seems far too pipe-dreamy to ever be built on a large scale.

philwelch 8y ago
> I'm specifically talking about the portion of rest that includes delivering actions with noun results, i.e. "Here's you comment record, if you want to edit it go to this URL, if you want to delete it here's a different one". How does that not describe a normal HTML page that has "edit" and "delete" links right next to the newly-created comment that it displays to you after you click the "reply" button on Hacker News? I mean, it's not automatic discovery, because you're relying on a human being to read a rendered web page and know what the links mean, but it kind of qualifies if you expect that the client is partially made of meat.
- munk-a 8y ago
  That's sort of the point, it was to remove the meat requirement on discovering those. Making the edit/delete/whatever forms and requirements machine readable so a stronger but still generic client tool can interpret them more intelligently. Again, I think it's naive since while a lot of stuff has plain CRUD operations, there are entities in most webapps that have more complex operations. If I were writing an application that partially managed cutlery in a restaurant it's not clear where a "clean" verb on a fork would fit into REST and how a generic client would understand what significance "clean" has especially as it relates to future eat actions. I have read through and understand the intent of the original RESTful system and I think there are some good and bad points. But, automatic discovery was definitely included in their vision of how it'd work, and actually seems like the center point TBH.
  - philwelch 8y ago
    > That's sort of the point, it was to remove the meat requirement on discovering those. Making the edit/delete/whatever forms and requirements machine readable so a stronger but still generic client tool can interpret them more intelligently. Hmm, that makes REST sound like it's pursuing similar ideas as the Semantic Web. > Again, I think it's naive since while a lot of stuff has plain CRUD operations, there are entities in most webapps that have more complex operations. If I were writing an application that partially managed cutlery in a restaurant it's not clear where a "clean" verb on a fork would fit into REST and how a generic client would understand what significance "clean" has especially as it relates to future eat actions. It isn't clear at all. It's possible, but in weird, hacky ways. Maybe when you're done with a fork, you DELETE the fork and then you can POST to /clean_forks/ to create a newly cleaned fork. And if you run out of forks to clean, it throws a 503 error. It's a terrible Kingdom of Nouns (https://steve-yegge.blogspot.com/2006/03/execution-in-kingdom-of-nouns.html https://steve-yegge.blogspot.com/2006/03/execution-in-kingdo...) but it might appeal to some people, for the same reasons that the original Kingdom of Nouns appealed to some people. After all, you get to feel clever and smart when you invent new design patterns to work around the limitations of your technology. Just writing a `clean_fork` RPC doesn't make you feel clever at all. In any case, while I can see automatic discovery as a useful feature for web browsers (who can still punt the actual decision-making to the meat, as long as they know what the plausible next steps would be), it doesn't seem likely to me that service clients would benefit from it any more than they benefit from a thoughtfully designed and documented RPC API. Meanwhile, for whatever reason, the end-user-facing web has decided to prioritize the use case of, "you will see and interact this web page according to The Original Creative Intention Of The Author" over the use case of, "here, have some data, it links together, do whatever the hell you want with it, I don't care what fonts or UI widgets you use". REST would have been great for the second use case; it's just that nobody cares about it anymore.
dsego 8y ago
I thought the general idea is to code the client against a well defined and sanctioned media type. If the media type returns items and actions, a well coded client should be able to handle it (whether it is to show it as GUI and provide controls or do some automated response etc). The point of returning actions is that URLs change, and must be able to change. Instead of following HATEOAS guidelines, people hardcode routes and lament about how URLs should be structured (flat vs nested, e.g. `/posts/1/commment/4` vs `/comments/4`) and then they also have to be versioned etc. (`api/v2/posts`). Now that is silly.
- philwelch 8y ago
  > If the media type returns items and actions, a well coded client should be able to handle it (whether it is to show it as GUI and provide controls or do some automated response etc). In a web service context, is there a HATEOAS web client library that I can use to make service calls without having to specify endpoints and request formats ahead of time? > Instead of following HATEOAS guidelines, people hardcode routes...and then they also have to be versioned etc. (`api/v2/posts`). In the web service use case, it's considerably simpler to define and specify a set number of endpoints ahead of time, define request and response formats, document that specification in OpenAPI, and use versioning if the API itself changes. This isn't RESTful. It's just RPC over HTTP. But it works and it's not "silly".
geezerjay 8y ago
> Also, I, personally, find that portion of REST to be silly. I like the organizational hints and guidelines, but the resource discovery seems far too pipe-dreamy to ever be built on a large scale. The amount of work really isn't that great when compared with having to layout routes. Proper HATEOAS is like unit testing: people complain it takes too much work but then complain that the lack of tests is a problem.