2 ms·

Your "fork" resource simply need to include a hyperlink to the cleaned self. Its no different then obtaining a "clean" page on the web, with the forms emptied,

Your "fork" resource simply need to include a hyperlink to the cleaned self. Its no different then obtaining a "clean" page on the web, with the forms emptied, etc... <fork> <a rel="clean_fork" href="http://example.com/very_clean_fork" http://example.com/very_clean_fork" /> </fork>

munk-a 8y ago
Indeed, and what does `clean_fork` mean? I don't disagree that it has some value, defining associated actions for the resources being served, I was more questioning how universal this approach could ever be. And bear in mind `<a rel="clean" href="http://example.com/database/clean">` http://example.com/database/clean">` would have a very different semantic meaning from `<a rel="clean href="http://example.com/fork/clean">` http://example.com/fork/clean">` or what have you. I agree that semantic actions are a thing it'd be nice to solve and I wanted to make sure this discussion on REST touched on the fact that semantic actions are something they tried to solve. But they didn't, we've assigned common meaning to common verbs (which is pretty sweet on its own) but everything else isn't discoverable. If you were a rather dumb client interface and got a `<a rel="clean_fork">` what would you do with that inherently except say "It isn't delete or put or patch, so I don't know what this does"
- droussel 8y ago
  Media-types and their semantic were always supposed to be sideband information, just as the meaning of <a> and <form> is documented in HTML. An easy way to think of it is that a Web Browser is a client for a REST architecture consisting of the web. If you create a new system and use a REST architectural style, the client app(s) will be the "browsers" for your API. When you implement a web browser, you do need to receive sideband information about the media-type (HTML) and your client application has to be able to understand those, including what <a> and <form> mean, for example. In a custom API, you use the same HTTP verbs if you want (REST doesn't mandate HTTP) but you need to define your media-types.

munk-a 8y ago

Indeed, and what does `clean_fork` mean? I don't disagree that it has some value, defining associated actions for the resources being served, I was more questioning how universal this approach could ever be. And bear in mind `<a rel="clean" href="http://example.com/database/clean">` http://example.com/database/clean">` would have a very different semantic meaning from `<a rel="clean href="http://example.com/fork/clean">` http://example.com/fork/clean">` or what have you. I agree that semantic actions are a thing it'd be nice to solve and I wanted to make sure this discussion on REST touched on the fact that semantic actions are something they tried to solve. But they didn't, we've assigned common meaning to common verbs (which is pretty sweet on its own) but everything else isn't discoverable. If you were a rather dumb client interface and got a `<a rel="clean_fork">` what would you do with that inherently except say "It isn't delete or put or patch, so I don't know what this does"

droussel 8y ago
Media-types and their semantic were always supposed to be sideband information, just as the meaning of <a> and <form> is documented in HTML. An easy way to think of it is that a Web Browser is a client for a REST architecture consisting of the web. If you create a new system and use a REST architectural style, the client app(s) will be the "browsers" for your API. When you implement a web browser, you do need to receive sideband information about the media-type (HTML) and your client application has to be able to understand those, including what <a> and <form> mean, for example. In a custom API, you use the same HTTP verbs if you want (REST doesn't mandate HTTP) but you need to define your media-types.