incubator-jspwiki-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Janne Jalkanen <>
Subject Re: REST-ful URLs [Was: url rewriting supported?]
Date Tue, 08 Jul 2008 17:03:38 GMT
> 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.


View raw message