[CherryPy] #897: RESTful dispatch proposal

[CherryPy]

#897: RESTful dispatch proposal
-----------------------------+----------------------------------------------
Reporter: d...@brattli.net | Owner: fumanchu
Type: enhancement | Status: new
Priority: normal | Milestone: 3.1.2
Component: CherryPy code | Keywords:
-----------------------------+----------------------------------------------
Attached is a new RESTful dispatch proposal based on
http://microformats.org/wiki/rest/urls. See test_rest.py for examples on
how to use.

It handles URLs such as:

* /people
* /people/345
* /people/edit/345
* /people/3/phones/5
* /people/4/phones/
* /people/phones/ringtones

It currently does not handle URLs such as:

* /people/3/phones/ringtones # gets the methods wrong
* /people/phones/5/ringtones # gets the args wrong

--
Ticket URL: <http://www.cherrypy.org/ticket/897>
CherryPy <http://www.cherrypy.org>
CherryPy - a pythonic, object-oriented HTTP framework

[CherryPy]

#897: RESTful dispatch proposal
-----------------------------+----------------------------------------------
Reporter: d...@brattli.net | Owner: fumanchu
Type: enhancement | Status: new
Priority: normal | Milestone: 3.1.2

Component: CherryPy code | Resolution:
Keywords: |
-----------------------------+----------------------------------------------
Comment (by d...@brattli.net):

Added a new revision. Now the params are added to request.params with
"{resource}_id" as key which fixes the problem of subcontrollers now
knowing which arguments is for itself or for the parent controller. It
also fixes any problems with not specifying any parameters between the
resources. Thus URL combinations like the ones below are not a problem
anymore.

* /people/3/phones/ringtones
* /people/phones/5/ringtones

The patch is even simpler than before.

-- Dag

[CherryPy]

#897: RESTful dispatch proposal
-----------------------------+----------------------------------------------
Reporter: d...@brattli.net | Owner: fumanchu
Type: enhancement | Status: new
Priority: normal | Milestone: 3.1.2

Component: CherryPy code | Resolution:
Keywords: |
-----------------------------+----------------------------------------------

Comment (by fumanchu):

I'll keep meta-comments on the ML for now. Here, I just want to point out
that line 238 in v2 seems buggy:

{{{
#!python
request.params[path_info[path_info.index(param)-1]+self.suffix] = param
}}}

For example, a URL of /people/1/phones/1 would result in request.params =
{'people_id': '1'} I think, because the value is repeated. At the least,
we need a test proving that one way or the other. ;)

[CherryPy]

#897: RESTful dispatch proposal
-----------------------------+----------------------------------------------
Reporter: d...@brattli.net | Owner: fumanchu
Type: enhancement | Status: new
Priority: normal | Milestone: 3.1.2

Component: CherryPy code | Resolution:
Keywords: |
-----------------------------+----------------------------------------------

Comment (by d...@brattli.net):

A URL of /people/1/phones/1 gives request.params = {'phones_id': '1',
'people_id': '1'}

Did you mean /people/1/people/1 ? It should only be a problem if the
resource is repeated, not the value. But then it's only a problem if the
value is not repeated such as /people/3/people/4. Not sure if such a URL
makes sense.

[CherryPy]

#897: RESTful dispatch proposal
-----------------------------+----------------------------------------------
Reporter: d...@brattli.net | Owner: fumanchu
Type: enhancement | Status: new
Priority: normal | Milestone: 3.1.2

Component: CherryPy code | Resolution:
Keywords: |
-----------------------------+----------------------------------------------
Comment (by d...@brattli.net):

Added a patch that shows the difference of using RestDispatcher vs
_cp_dispatch. Both ways I need to change MethodDispatcher in order to
allow for REST style verbs such as "new", "edit" etc.

So I think I throw in the towel. The _cp_dispatch way is both more
flexible and much faster. I will strip down the patch to be just the few
lines for the MethodDispatcher. The test_rest_cp_config should be written
into a tutorial or something.

[CherryPy]

#897: RESTful dispatch proposal
-----------------------------+----------------------------------------------
Reporter: d...@brattli.net | Owner: fumanchu
Type: enhancement | Status: new
Priority: normal | Milestone: 3.1.2

Component: CherryPy code | Resolution:
Keywords: |
-----------------------------+----------------------------------------------
Comment (by d...@brattli.net):

Notice that the latest patch
(http://www.cherrypy.org/attachment/ticket/897/rest_dispatch-v5.diff) now
depends on the _cp_dispatch feature of #869

[CherryPy]

#897: RESTful dispatch proposal
-----------------------------+----------------------------------------------
Reporter: d...@brattli.net | Owner: fumanchu

Type: enhancement | Status: closed
Priority: normal | Milestone: 3.2
Component: CherryPy code | Resolution: toolfix
Keywords: |
-----------------------------+----------------------------------------------
Changes (by fumanchu):

* milestone: 3.1.2 => 3.2
* resolution: => toolfix
* status: new => closed

Comment:

Good move switching to `_cp_dispatch`, but I think that now we have
`_cp_dispatch` in 3.2, this doesn't need to be in the distro. A page at
http://tools.cherrypy.org would be best.