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 just want to be an advocate of standards and not slip into the
"Internet Explorer Development Methodology". Eventually browsers will
support this stuff, in the mean time, using strict REST makes
webservices so much easier.
_______________________________________________
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/
