[xwiki-devs] GSOC idea: RESTful XWiki

[Erin Schnabel]

On Wed, Mar 5, 2008 at 10:38 AM, Sergiu Dumitriu <sergiu at xwiki.com> wrote:
>  No, we didn't quite disagree. I was not talking about the
>  implementation, but about the design of the implementation. If we would
>  write some restlets, then they would do what?
>
>  Let's say we have the URL http://server/Space/Page/ and do a:
>  - GET: duplicate some of the code in ViewAction
>  - PUT: duplicate some of the code in SaveAction
>  - DELETE: duplicate some of the code in DeleteAction
>  - POST: duplicate some other code in SaveAction
>  - HEAD: write some new code, as this is not done yet
>
>  So I was saying that when designing the URLs, we should redesign the
>  application logiC (and this is something you implied, too), but put it
>  not in the restlets, but in another layer, so that it can be reused by
>  other protocols. You do agree that we can't just design new URLs (or
>  should we say IRIs?), without designing the logic behind them.
>
>  Currently the logic is spread around all the platform. There is code in
>  the Struts actions, in the XWiki giant, in the data model, in templates,
>  in documents, in plugins (FileUpload, for example), so writing restlets
>  that reuse this spread logic will be very inefficient:
>  - search all around the code to see how to do something
>  - duplicate code
>  - copy the bugs along with the code
>  - increase even more the mess
>
>  And we can't just completely replace the servlets (and their URLs) with
>  the new REST approach, as all the bookmarks and knowledge about the URLs
>  would be broken, so people will not upgrade. So we either reimplement
>  them using the new app logic layer, or write an URL rewrite engine that
>  forwards to the new IRIs.
>
>
> --
>  Sergiu Dumitriu
>  http://purl.org/net/sergiu/
>

I completely agree with this, and think that consolidating the logic
so it isn't spread across so many places would also simplify life for
those of us that want to put a completely new face on things (so to
speak).

I have also been bitten by the crawler bug: Some of the delete actions
are/were regular URLs relying on Javascript for confirm/deny... I've
seen a bot with read access start deleting things.. (in the absence of
javascript, the URL is effectively "clicked", causing the action to
happen.. ). That's a little tangential to the discussion, but
consolidating where the logic is for managing deletes, etc. would be
good.. It might also make the path length a little shorter, if you do
it right..


-- 
'Waste of a good apple' -Samwise Gamgee