* Zbigniew Lukasiak <[email protected]> [2009-03-04 21:45]: > OK - does that mean that you agree that someone can build a > RESTful CRUD with that URI structure?
Yes, because one can do with almost *any* URI structure. :-) * Peter Karman <[email protected]> [2009-03-04 23:25]: > When I hear "RESTful URL" I interpret that as "URI-as-a-noun" > (or more negatively-defined, "URI-with-no-verbs"). > > Perhaps we should use something like "REST-friendly URL"? > > [0] e.g., > http://www.mail-archive.com/[email protected]/msg01712.html Yeah. And URIs-as-nouns is a good goal that should be encouraged, absolutely. URIs should identify resources, not operations, that is true. However, putting too much emphasis on the structure of URIs is at the same time problematic, because while it drives people away from a terrible style, it also pushes them in the direction of another bad style (however a less problematic one, to be sure). They forget to put links into their output documents, instead putting application-specific IDs in there, and then they publish API docs that consist of tables of URI construction rules. Then clients have to be hardwired for the interaction between those IDs and the URI construction rules. Which is exactly the opposite of REST. In REST, URIs are opaque as far as the client code is concerned. Clients only ever know what URIs to follow because they get them as links or build them from forms or URI templates they find in the content of server responses – *at runtime*. Not hardwired in. The documentation of an actually RESTful API explains the format of the server response and where to find links in it, as well as what methods can be used against what type of link, and for what purpose. The server URI structure is totally irrelevant. If it changes tomorrow, and then again the day after, and again next week, you don’t need to care; the response format is the same (or actually, gets extended in compatible ways) so you can still find the links in the right places and the client magically keeps working while the server completely changes its implementation and turns its URI structure upside down. *That* is the point of REST: completely decoupling servers and clients from each other. Good URI design is useful as a usability issue for humans OT1H (bookmarkability, hackability etc are usability concerns), and as a server implementation concern OTOH. But it’s entirely orthogonal to the principles of REST. Regards, -- Aristotle Pagaltzis // <http://plasmasturm.org/> _______________________________________________ List: [email protected] Listinfo: http://lists.scsys.co.uk/cgi-bin/mailman/listinfo/catalyst Searchable archive: http://www.mail-archive.com/[email protected]/ Dev site: http://dev.catalyst.perl.org/
