[Catalyst] RFC: Catalyst::Controller::REST::DBIC

[Zbigniew Lukasiak]

On Mon, May 5, 2008 at 11:36 PM, luke saunders <luke.saunders at gmail.com> wrote:
>
>
>  >  >  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.
>
>  I think that's a pretty reasonable suggestion. It doesn't solve the
>  different object lookup methods point, but I think it's reasonable for
>  that to justify a subclass.
>
>  However, I do still have a nagging feeling that having /foo/create and
>  /foo/-/{token} is preferable because it's easier to not make an action
>  with a PathPart of "-" than it is to not have a record whose identifer
>  is "-". But I accept that your method would mean that the "-" is only
>  seen if you want non-standard methods.

How about /foo/instance/{token} ?  This way it would be clear that
'foo' is just the name of the object class and that the object for
REST operations is in /foo/instance/{token}.

-- 
Zbigniew Lukasiak
http://brudnopis.blogspot.com/