[Registry-dev] URLs for comments and tags

[Glen Daniels]

(meant to send this from glen at wso2 - Thunderbird config should now be fixed)

Hi Paul, all:

Paul Fremantle wrote:
> Chathura
> 
> I prefer the second approach. However, maybe I'm wrong here, but I see 
> comments as something "external" to the core registry space, just like 
> the metadata is. In other words, I wouldn't represent the last modified 
> date of a resource as another resource. The LastModified date is 
> metadata (in the context of the registry)

Deciding what's a resource and what's metadata is as tricky as deciding 
how a given class/object structure should look - one man's bit of 
metadata is another man's URL-addressable resource.

 From my POV, I definitely think that there is a lot of value in having 
tags and comments both be addressable as first-class Resources in the 
URL space.  Maybe it's just because I'm in the midst of the RESTful Web 
Services book, but this seems like a slam-dunk to me. :)   While it's 
true that the backend implementation needn't follow the RESTy style of 
the HTTP interface, I sort of prefer that they stick as close as 
possible.  And I think a put() to "...myResource/comments/23" to edit a 
comment is nicer than a separate "editComment" API.

> In the same way, I think comments are metadata, not data. Tags are 
> interesting, because of course I want to browse /tag/employee and see 
> the list of tagged items. However a "tagging" is also metadata. The 
> /tag/employee is a dynamically created resource which is a collection of 
> links to tagged resources.

I'm not sure I entirely understand this paragraph.  See above re: 
comments, and re: tags, I think we should support something like:

registry/resource1/tags (get list of tags on resource1)
registry/user/glen/tags (get list of all tags I've used)
registry/user/glen/tags/yellow (list of resources I've tagged yellow)
registry/tags/yellow (list of resources anyone has tagged yellow)

(all of these of course only show you what the authenticated user has 
access to view)

I think (but I'm not positive) that I actually prefer the path-component 
approach, because it gives us the flexibility to do something like 
"resource1/comments/1/comments/1" (someone has commented on the first 
comment on resource1 - i.e. threaded discussion).  I don't think 
reserving the names "comments" and "tags" will be a particularly big 
deal.  I need to think about this a bit more.

--Glen