incubator-jspwiki-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Andrew Jaquith <>
Subject Re: REST-ful URLs [Was: url rewriting supported?]
Date Mon, 07 Jul 2008 22:40:17 GMT
Murray --

The kind of URL scheme you describe is very interesting, and it is  
indeed related to this whole discussion on URL construction.  
URLConstructor isn't the best name, really, because it actually  
understates its role. It also performs URL *parsing*.

My earlier message about URLRewrite relates to this. On the inbound  
side, "something" needs to transform the long URL (

) into a proper resource path, with parsed and decoded parameters.  
URLRewrite does this, as a filter. So does our own WikiServlet filter,  
albeit not using the syntax you gave.

For 3.0, my preference has been to use a plain addressing scheme like  
the current DefaultURLConstructor. It doesn't require any special  
decoding/remapping on the inbound side, and outbound URL construction  
is easy. However, an URL scheme like the one you suggested is good  
too. In theory, we could use URLRewrite. Janne has also raised  
concerns about performance because of its reliance on regular  
expressions. I am less concerned about that, and more concerned about  
the fact that you need to be able to reference the HTTP response  
object (and its encodeURL() method) to make it work.

The other approach would be a new ("better") URL constructor scheme.  
Either way, we will continue to need 1) a filter (to remap the  
incoming URLs to a proper request format and forward the correct  
destination JSP) and 2) some kind of URL construction algorithm.


On Jul 7, 2008, at 4:24 PM, Murray Altheim wrote:

> One of the things I've been working on (both related and unrelated to
> JSPWiki) is a web service URL schema providing read and write access
> to the wiki, in particular the wiki's page provider. Without going
> into detail about that I thought I might at least mention the idea
> of REST-fully regularizing *all* of the URLs used by JSPWiki to a
> common approach, i.e. (optional components in square brackets):
>   baseURL collectionHierarchy [objectId] action ['?' parameters]
> e.g.,
>  pages/  PageName/  get/
> This would in the future permit a collection hierarchy where 'pages/'
> currently exists, with 'PageName' as object ID (oid) potentially
> replaced by any kind of identifier (pages may be identified by name
> or by some other kind of identifier that survives across renames --
> title).
> (the actual action names aren't important) or alternately, including
> the action name as a parameter:
> allowing things like:
> etc., with advantages and disadvantages to each.
> Has there been any thought amongst other members of the team in  
> writing
> a more REST-ful URL constructor? Perhaps as the default? While I do
> understand dealing with legacy issues it'd be nice to just have a  
> simple,
> REST-ful URL that just worked. It's been one of those things I've  
> never
> been able to get working consistently in JSPWiki across all
> installations.
> I don't have it working yet but I basically have been writing a web
> service that would provide complete access to the wiki's functionality
> using a schema similar to the above. The question for me is how
> difficult it'd be in rewriting the JSPs to generate URLs as according
> to the web service instead of the existing setting, which of course
> led me to think that the whole web service is really just an  
> alternative
> URL constructor...
> Murray
> ...........................................................................
> Murray Altheim <murray07 at>                            
> ===  = =
>                                     =  
> =  ===
> SGML Grease Monkey, Banjo Player, Wantanabe Zen Monk               =  
> =  = =
>      Boundless wind and moon - the eye within eyes,
>      Inexhaustible heaven and earth - the light beyond light,
>      The willow dark, the flower bright - ten thousand houses,
>      Knock at any door - there's one who will respond.
>                                      -- The Blue Cliff Record

View raw message