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
