On 12/5/05, Kevin Dangoor <[EMAIL PROTECTED]> wrote: > > So, in a generic CRUD feature, what would you want your URLs to look like: > > 1) http://yoursite/articles/10/edit
This is the most natural. "articles" contains all articles. "10" is an article. "edit" is an operation on 10. "view" is the index method (/articles/10/). > 2) http://yoursite/articles/edit/10 Acceptable, but I don't like the 10 jumping levels. "article" as a collection of articles makes sense. "article" as a collection of actions doesn't -- people don't go to the site for actions, they go for articles. They also don't want to type /articles/view/10 into the location bar; they want a straightforward /articles/10 . The actions are just a means to facilitate article management, so they go to the right. An OO application has objects with methods, not methods with objects. /articles/10?action=edit Acceptable, but an action should arguably be part of the URL path. And it would mean one huge controller method that switched on actions, which contradicts the CherryPy structural philosophy of one small controller method per action. That's one of the main things that draws people to TG (and Quixote, which does the same thing). /article-10/edit Ugh, this goes back to the dark ages of parsing data out of strings. The thing between the "/" is supposed to be an identifier, not an identifier embedded into an arbitrary string. Numeric identifiers have many advantages such as sorting. Will article-100 show up after article-99 or between article-10 and article-11? I understand the point about treating the article ID as an arbitrary string, but then why incorporate a number at all? Still, numbers make more sense for a generic CRUD application because we don't know what all the user plans to do with the data, and numbers make it easier for them build any kind of local add-on. > 3) http://yoursite/articles/edit?id=10 This is frustrating when you're analyzing logs or implementing a caching system, and some third-party software has dropped the query string. Anything that's essential to identifying the resource belongs in the URL path. -- Mike Orr <[EMAIL PROTECTED]> ([EMAIL PROTECTED] address is semi-reliable)
