Hello,
Looking at the proposal again, I feel it has a very document oriented
perspective and does not do justice to the primary use case of a wiki
which is collaborative work. So for instance, a user is not viewed as
a resource. That means that if I want to know what a user's recent
activity on a space that we share, well it would probably require some
processing with the current api. I would have liked to have done
something like a GET on
/users/{userId}/spaces/{spaceId}/recent
Anyhow that is a real common use case, who has done what on a shared work space.
The notion of a group of users is also missing so it wouldn't be so
simple to let's say to have a client that allows me to send an email
to my group. Whereas something like getting
/groups/{groupId}
would probably be quite sufficient, another common use case.
Finally, since some of this might seem useful for these basic
elements, it might also be useful for XWiki classes in general to be
able to expose a bit of RESTful api. So let's say I implemented a
friends feature by linking user objects, I would certainly like to
expose something like a GET on
/users/{userId}/friends
So I think one of the requirements in the design is to allow this type
of behavior, maybe by linking a script to an object that describes the
api and is attached to the XWiki class.
More thoughts...
--
Luis Arias
+33 6 14 20 87 93
skype : kaaloo