Sorry for the typo. (loose -> lose) Could we also need the selectors(as I earlier mentioned but probably did not get noticed): - All objects of the class {className} in a {page}, {page}'s {version} or the entire wiki? /objects/class/{className}/ /space/{space}/page/{page}/objects/{className}/ /space/{space}/page/{page}/history/{version}/objects/{className}/ possibly with the added: [?start=offset&number=n] Fabio Mancinelli wrote:
Eduard Moraru wrote:
Hi, here's my 2 cents re the first proposal...
Why do we have separation between objects and tags/comments? Shouldn't the objects mapping be enough to handle them?
Of course objects are enough to handle them but since comments and tags are very "useful" objects imho it's worth to expose them *also* as separate resources that can accept specific media types.
I mean, imagine you want to tag a page. If you have /spaces/{space}/pages/{page}/tags
You can do a POST to that URI by sending, for example, just the new tag. Something like:
curl -d "foo" http://localhost:8080/spaces/Main/pages/WebHome/tags
If you handle this *only* with objects you will need to post a more complex media type, typically an XML containing the property name, value, etc.
Same thing for comments:
curl -d "I like this page" http://localhost:8080/spaces/Main/pages/WebHome/comments
And does it make sense to have this, when we already know the guid of the object we want:
I agree that with guid the old way of identifying objects is useless. I put it in the resource list because it is the current way of identifying objects. And maybe somebody has a reason to leave it.
The drawback would be that we loose: * /tags/{tag1}[,{tag2},{tag3}...][?start=offset&number=n] (The list of pages tagged with tags {tag1}, {tag2}, {tag3}, ...) Of course, we could still have it as a convention or we could even create a generic way of getting this result with other objects as well.
I don't understand why you say we "loose". If we want to expose a /tags resource we can do this. And I think that it's a resource worth to be exposed.
Related to pages, we could also have: * /pages[?start=offset&number=n] (The list of available pages in the space in the entire wiki) Could we need it?
Probably for indexing purposes that could be useful.
Thanks.
P.S.: From what I asked around, it seems that attachments are not objects. That seems weird to me because, intuitively, the attachments should be objects on a page of the class Attachment. On attachments you have versioning, meta-data and an attachment can exist on a page or not, the behaviour of an object. Could anybody explain the reason for this please?
AFAIK, it's for historical reason. Yesterday I was asking ThomasM how attachments work because me too I found it a bit counterintuitive.
Thanks.
-Fabio _______________________________________________ devs mailing list [email protected] http://lists.xwiki.org/mailman/listinfo/devs