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 Tue, 08 Jul 2008 20:46:59 GMT
Interesting thread! You guys had me at a disadvantage -- I was on a  
plane from Latin America this morning, and have not been able to  
respond until now.

I think I smell a resolution in the air. It is, indeed, to use Stripes  
as the "backing technology" for short URLs. Doing this gets us  
compatibility with all three current URLConstructors. Here's why:

First, let me state what I think I heard from Janne.

#1: we have to stay compatible with ShortURLConstructor
#2: we have to stay compatible with DefaultURLConstructor too
#3: Janne has no interest in coming up with a new scheme, but is happy  
to let "others" (read: Murray) go crazy if they want to, outside of  
the core distro
#4: despite restrictions 1, 2, and 3,  the URL scheme needs to somehow  
accommodate subpages and wiki spaces
#5: we assume that the delimiter for spaces and sub-pages is the same  
as the one separating subpath in the URL (/)

Assumption #5 is dubious IMHO, but let's assume all of the others are  
hard requirements. Even with these constraints, we can still use  
@URLBindings for inbound parsing. Here's why:

DefaultURLConstructor is just the JSP path with appended parameters.  
Because every top-level JSP will have a stripes:useActionBean tag in  
it, Stripes will automatically do its magic resolve-bind-execute-event  
thing regardless, when the JSP is directly addressed. So if we have  
URLs that are of the "default" form, we are covered.

As for "short form" URLs, our current URL syntax could be handled by  
the "clean URL" @URLBinding syntax quite easily. Janne, you might not  
realize this, but the clean URL format is more flexible than you  
think. It does not require an exact match; just the firrst part of the  
URL needs to match. If the remainder is a series of appended  
parameters (in normal '&' syntax), these are bound as normal  
parameters. So you do not need to specify an URLBinding that includes  
absolutely every parameter you would ever need to bind -- just the  
important ones. That is exactly how short URLs work today, no?

So -- if we have 1) the DefaultURLConstructor covered via  
stripes:useActionBean and 2) the ShortURLConstructor covered via  
URLBindings, then by definition we also have 3)  
ShortViewURLConstructor covered. Requirement #3 (other URL schemes) is  
not met, but there is always mid_rewrite for those cases.

The wildcard here is what happens with wikispaces and nested pages.  
Best case: Stripes does not care what is used as a delimiter, even a  
'/'. Worst case: Stripes does care, so we use a different delimiter,  
like a colon.

Now, this kind of throws out Murray's particular scenario, but it does  
neatly give us, essentially, solid backwards compatibility and much  
better request binding, and great forward compatibility. We would  
still need an improved URL constructor class for the short URL case,  
which would rely on the URLBindings for instructions on how to make  
the URLs.

We would effectively be trading code for annotations. Personally, I  
think that is a good thing, because it makes it easier to create new  
ActionBeans (features!)


On Jul 8, 2008, at 12:03 PM, Janne Jalkanen <>  

>> I'm thinking that perhaps Andrew and I might be able to fix it via
>> Stripes. I don't know how big the library is but if it's not big we
>> could possibly introduce Stripes into the mix as the backing  
>> technology
>> for the ShortURLConstructor, which would ease *everyone* into the 3.0
>> path since they could begin to use the new schema for all new sites
> I don't really see any way that we could use Stripes here.  And  
> personally, I would not use a new scheme...  So it certainly  
> wouldn't help my job ;-)
>> The 'collectionHierarchy' is in the current wiki a single token but
>> *could* be deeper. Given I don't think we'd want arbitrary depth
>> (I may be wrong) then there's only the possibility that we might
>> go from "Main" to "Main/SubMain". That shouldn't be a big problem
>> if we design the schema such that the verb is either at the very
>> end or part of the query. So "Main/edit" can only be a page reference
>> if it's "Main/edit/verb/" (e.g., "Main/edit/edit/") or
>> "Main/edit/?action=verb". This shouldn't be a problem.
> It is, because Stripes CleanURLs assume static paths - item #1 is  
> always something, item #2 is something else, etc.  Stripes cannot  
> guess when a slash is a part of a page name, and when it is an  
> action.  The CleanURLs are nice, if you are developing an app from  
> scratch.  It's not so nice trying to retrofit existing URLs.
> This means a separate parser, and that means an URLConstructor (or  
> something similar).  Which again means that Stripes is nice, but I  
> think this particular idea is wholly unsuited for the problem at hand.
>>> Well, the URIs *are* already RESTful. ;-)
>>> (In fact, /Edit.jsp?page=Foo is also RESTful.  Most people just  
>>> like to hide the technology [jsp in this case] by using neutral  
>>> URIs like /edit/Foo).
>> Yes, I have an absolute, unbendable requirement that we have to hide
>> implementation details from the URLs. So if one's definition of  
>> RESTful
>> includes hiding implementation details (and mine does), then this  
>> is a
>> necessity. In my actual case it is a requirement.
> Well, you are entitled to define the words anyway you want, but  
> don't expect us to adhere to the same definitions.  JSPWiki is  
> already RESTful in the commonly agreed definition.
>> etc. I'd also like to be able to do PUTs via a RESTful interface in
>> addition to the human UI so we can remotely populate a wiki from an
>> external site, for synchronization, etc.
> I highly recommend that you implement the Atom Publishing Protocol  
> then.  It's pretty much the standard these days.  We have the basics  
> in place, but we should really switch to a better library, since the  
> current implementation does not support APP 1.0.
> The other possibility is to start working on the DAV interface  
> (which defines all your metadata stuff in a commonly agreed language  
> instead of redefining the meaning of the HTTP verb HEAD ;-).  The  
> DAV stuff mostly works, but it's client-specific.
> Both are REST.
> I'm not sure whether we would need a third one.
> /Janne

View raw message