[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
Re: AtomPub Media Repository
On Feb 10, 2010, at 8:53 AM, Asbjørn Ulsberg wrote:
> 2010/2/8 Asbjørn Ulsberg <list@xxxxxxxxxxxxxxxxxx>
>
> So, I'm thinking the URIs would look a little something like this:
>
> http://example.com/
> http://example.com/acme/
> http://example.com/acme/templates/
>
> http://example.com/acme/photos/
> http://example.com/acme/photos/chrome/
> http://example.com/acme/photos/products/
> http://example.com/acme/photos/illustrations/
>
> Hm. From what I can tell by RFC 5023, I can have:
>
> 1. Only one level of work spaces on the web sites. These can't be nested.
> 2. Only one level of collections within each work space. These can't be nested.
> 3. As many levels of categories I want through altering "scheme" values, like so:
>
> <categories fixed="no">
> <atom:category scheme="http://example.org/acme/photos/" term="chrome" />
> <atom:category scheme="http://example.org/acme/photos/" term="products" />
> <atom:category scheme="http://example.org/acme/photos/products/" term="hats" />
> <atom:category scheme="http://example.org/acme/photos/products/" term="mittens" />
> <atom:category scheme="http://example.org/acme/photos/" term="illustrations" />
> </categories>
>
> Is this perfectly fine? As far as I can tell, this allows for an extensible category tree that can be freely manipulated by the client.
Yep.
> The only challenge I can see is how to manage existing categories; renaming, deleting, etc.,
Make resources that have the proper semantics, maybe make categories entries themselves and manage like any other item
PUT /categories/vehicles/cars/japanese-cars/title
Content-Type: text/plain
[New title]
303 See Other
Location: /categories/vehicles/cars/japanese-cars
[full new category representation]
> as well as moving entries from one category to another.
POST them to the collection that they should be in or delete their member entries. Note that collection member can be a different resource than the resource that is a member.
>
> I've thought about tackling each of these like so:
>
> - Moving entries from one category to another: PUT the entry with the new atom:category element in it, effectively removing the association with the old category.
Might also be ok, yes.
> - Deleting a category: Move all entries out of the category, effectively making the category void which can implicitly be translated to "deleted" by the server.
Yes, possible
> - Renaming a category: Say the old is called "hats" and should be renamed to "headwear", you would create the "headwear" category, then move all entries from "hats" to "headwear".
That is not a renaming but a move. Do not put soomething that might change (e.g. cat title) into the URI. Only use key-like attributes.
>
> That seems to solve all obstacles I can see, but the question is: is this kosher per RFC 5023? I can see a problem in the rename/moving algorithm if a category contains a large amount of entries as you would need to PUT each individual entry, which could take a lot of time.
Yes. Renaming the category should really be an update of the corresponding resource itself.
Jan
>
> --
> Asbjørn Ulsberg -=|=- asbjorn@xxxxxxxxxx
> «He's a loathsome offensive brute, yet I can't look away»
-----------------------------------
Jan Algermissen, Consultant
NORD Software Consulting
Mail: algermissen@xxxxxxx
Blog: http://www.nordsc.com/blog/
Work: http://www.nordsc.com/
-----------------------------------