to REST or not to REST?

[zby]

I am the author of a scaffolding for Catalyst (Catalyst::Example::InstantCRUD). The purpose of it is two-fold - first you can treat it like you treat h2xs or ExtUtils::ModuleMaker - something that generates a template. Second it is meant as a learning tool - it generates a working application so one can check how it works and try to customize it. Currently it uses a traditional URI schema: /name/view/id, /name/edit/id etc. I am thinking about adding a REST functionality to it - but this would mean quite a bit of changes:

• Changing the URI schema to less intuitive:

     # POST         /foo                -> create new record
     # GET          /foo                -> list all records
     # PUT          /foo/by_id/<pk>           -> update record
     # DELETE       /foo/by_id/<pk>           -> delete record
     # GET          /foo/by_id/<pk>           -> view record
     # GET          /foo/by_id/<pk>/edit_form -> edit record form
     # GET          /foo/create_form    -> create record form
  

  or similar.
• But perhaps more important it would also mean using the machinery for serializing the content based on the HTTP Requests content-type header (see Catalyst::Controller::REST).
• And finnaly it needs additional dispatching mechanism - so that the queries are routed to methods called foo_PUT or foo_DELETE (see as above).

So it introduces a lot of complications - that would be an additiona obstacle for those that don't want to go the full REST path, both the learners and those who just use it as a template generator. Among the other frameworks I see that Django uses the traditional URI structure - and I think Rails uses REST.

Do you thing REST is worth those complications? Or maybe I should generate two applications: one RESTful and another one more traditional (in two additional subdirs)? Or maybe you have some other ideas?

[sundialsvc4]

Certainly I feel that you are now constrained by your “installed base” to offer whatever you have in mind as an alternate to what you have already supplied to CPAN. You've got no way to know (AFAIK...) just how many times your work may have been deployed “in production” by somebody-out-there.

Yes, I think that “RESTfulness” might be perceived as advantageous for an “instant CRUD” product. It might therefore be an alternate package that you want to implement, thus providing your customers with a useful option.

[bellaire]

The benefits of REST (in this case) seem to be semantic. I don't think there's any inherent benefit other than the fact that if you are familiar with REST and you like the way it works, then this will seem natural to you. I'm not sure that it's worth the modifications to the dispatch method. In particular, I think the question you need to be asking is whether or not RESTful applications are commonplace using Catalyst or not (who cares about other frameworks?). If they are, or if there is a demand, then it could be a good idea. If not, I'm not sure it's worth the effort. In any event, if you do go forward with it, I'd have it as an option (or dual setup as you suggested) rather than switching completely away from the traditional Catalyst dispatch method.

[zby]

Well - I am asking this here exactly to test the demand :) Pure REST certainely is not commonplace in Catalyst now - but perhaps there are people who would like to switch to more RESTful schema?