Yes, understood. I'm thinking it might be a fourth URLConstructor
scheme
since it won't completely replace (plug-and-play wise) any of the
existing schemes. And as I mentioned to Andrew, I'd like to be able to
literally re-use it to invoke another web service layer on top of
JSPWiki (for preservation, interwiki, and other potential services).
If you're in a hurry, I would look into a specific URLConstructor...
I doubt 3.0 will be ready for a long time.
I'm not much on hype myself, and while I do agree that the
ShortURLConstructor
is either very close to or exactly matching the URL schema I'm
considering,
there are some problems with the existing implementation *and* I
believe
I may have a requirement to load the verb on as the latter token
rather
than being included in the query string. I don't want to quibble
over the
definition of RESTful either, but I may need to replace that latter
URL
You could fix the ShortURLConstructor ;-)
ShortURLConstructor - uses path-like reference style:
http://mywiki.com/jspwiki/wiki/Main
http://mywiki.com/jspwiki/wiki/Main?do=Edit
with
http://mywiki.com/jspwiki/wiki/Main/edit/
Both of these are RESTful, with the added bonus that the latter will
break once we have sub-pages and someone creates a page called "Main/
edit".
Which, BTW, is also a big problem with CleanURIs.
Yes, certainly. We're dealing with government/corporate cooperative
team
designing and implementing an enormous application that is entirely
built
on this principle. There are RESTful URLs all through the
application and
I've got a requirement to hook JSPWiki into that. It would be
lovely if
the URLs that the user sees when using the wiki are the *same* ones
(or
are from at least the same schema) as the ones hooking the wiki
into the
preservation system, which is why I'm excited by Andrew's latest
missive.
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).
/Janne
