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