On Mon, May 5, 2008 at 1:10 PM, luke saunders <[EMAIL PROTECTED]> wrote: > > On Mon, May 5, 2008 at 6:16 PM, J. Shirley <[EMAIL PROTECTED]> wrote: > > > > On Mon, May 5, 2008 at 9:51 AM, luke saunders <[EMAIL PROTECTED]> wrote: > > > On Mon, May 5, 2008 at 5:19 PM, J. Shirley <[EMAIL PROTECTED]> wrote: > > > > On Mon, May 5, 2008 at 8:18 AM, Andrew Rodland <[EMAIL PROTECTED]> > wrote: > > > > > On Monday 05 May 2008 09:50:08 am J. Shirley wrote: > > > > > > On Mon, May 5, 2008 at 4:31 AM, Matt S Trout <[EMAIL > PROTECTED]> wrote: > > > > > > > On Sun, May 04, 2008 at 09:06:30AM -0700, J. Shirley wrote: > > > > > > > > > > > > I fail to see how whether the PK is the lookup key or not > has any > > > > > > > relevance at all to the original point, which was "your > lookup key and > > > > > > > names of actions might clash so it can be nice to have an > extra path > > > > > > > component such as 'id' for the lookup part to disambiguate". > > > > > > > > > > > > Because I'm talking about REST and a verb in the URI doesn't > need to be > > > > > > there. > > > > > > > > > > But those nouns you're talking about aren't verbs at all. > > > > > > > > > > Andrew > > > > > > > > How is /create, /edit or /delete not a verb? > > > > My argument is separate to the /create is valid in the /foo/{token} > > > > bit. I'm saying that /foo/create is silly to have in the first > place ... > > > > > > Okay, let me clear this up. Originally the plan was to have a > > > centralised REST-style action which dispatched POST/PUT/GET/DELETE > > > requests to the appropriate actions while also providing RPC-style > > > verb actions as an alternative for use if the client didn't properly > > > support the REST request methods. Having listened to discussion in > > > this thread I think it would be better to make the module pure REST > > > and then provide the RPC alternative through a subclass, perhaps also > > > integrating Catalyst::Request::REST::ForBrowsers into the REST version > > > as suggested. > > > > > > > > > > If you apply actual REST principles, you don't have such nonsense. > > > > But again, as I said, this is if you are working with REST. If REST > > > > doesn't fit your application model, don't use it. Just don't name > > > > things REST when they are really CRUD. > > > > > > Why can't CRUD be RESTful? > > > > > > In fact my revised plan is to glue together a base REST module and a > > > base CRUD module and add the list method discussed somewhere else in > > > this thread to provide a complete default RESTful module. Ideally the > > > REST base module could be swapped for an RPC style base module to > > > easily provide an RPC alternative of the same thing. > > > > > > > REST and CRUD are not mutually exclusive, but implementations can be. > > > > When I see things like /book/create, /book/1/edit I see CRUD (or RPC) > > but not REST. REST also doesn't have to be CRUD. I have a REST > > application that is more CR. It just posts immutable records and > > provides findability on those records. > > > > The discussions about a better CRUD base class with REST and RPC > > adapters is obviously the better (best?) solution, but I also think > > there will be significant disagreement between appropriate URI > > resource conventions (as my exchange with zby is an example of.) I > > haven't had enough time to actually proffer any code, but since this > > is a central focus of my development as late I'm very opinionated in > > these matters :) > > I think that the /foo/{token} vs /foo/id/{token} is the only point of > contention. And it would definitely be nice if an agreement could be > reached on this. Indeed, if I do develop this further it would make > sense if the REST base class is your own > Catalyst::Controller::REST::DBIC::Item.
If people are ok with the verbs being in the URL as a sacrifice to broken browsers, agreed :) I'm going to be rounding out the tests for my work, and I'm giving a talk on it at YAPC::Asia. It's mostly just my thoughts on how things go, but the work is from a web-services point of view, with some browser views. I'll post my slides up (and there may be video fo the talk) afterwards. > To me the /foo/{token} URI is only acceptable if it is understood that > no further custom object level URIs can then be added > (/foo/{token}/disable for example) and that lookup can only ever be by > {token} rather than {name} or something else. For REST I can see that > this is possible but I do feel that putting something between the base > and the token to clearly identify it as object level is generally the > safest option. I like to map my URLs out in a definitive hierarchy. If people want an implicit create action, a /foo/-/create looks better to me than having /foo/create, because I have the level of /foo to be the plural, /foo/{id} to be the singular (in a simple CRUD example). /foo/-/create is fine, because you can have a rule that "-" is never an acceptable record identifier. All of this stuff is mostly just standardizing on a set of ideas, which leads into your next point: > Peter made a fair point that if you don't like it you can subclass and > change, but agreeing on a best practice and making that default is > obviously desirable. Agreed :) My vote is hierarchy like: /foo /{token} # Can be pk1 if you so desire /- # - is never acceptable as an identifier /create # if you want an empty action here Now, I do vote against having an explicit create action, since "POST /foo" (or "POST /foo/{token}") seems to be a more reasonable create action. -J _______________________________________________ List: Catalyst@lists.scsys.co.uk Listinfo: http://lists.scsys.co.uk/cgi-bin/mailman/listinfo/catalyst Searchable archive: http://www.mail-archive.com/catalyst@lists.scsys.co.uk/ Dev site: http://dev.catalyst.perl.org/