On Thu, Jun 10, 2010 at 12:46 AM, Adriano Crestani <[email protected]> wrote: > Hi Luciano, > > The rest proposal looks good, some comments/questions below. > > Should we still keep the current model where images belong to a single > album? Phillipe's scenario, where he describes aggregated albums > referencing pictures that do not belong to them, would not work as > expected if we keep this approach, because a deleted album might > affect the contents of another album. I would also vote for a model > where pictures belong only to the gallery and albums only referencing > them. If we follow such model, the following rest APIs would need > changes: >
So, I have entertained this approach as well, (and this is the approach taken by Flickr). My view is that this brings some complications: - How to support this in a file system based gallery ? - How album subscriptions work on this scenario ? Is it just going to be "lost" under the "all images" photo stream ? Do we force it to have an associated tag, which really then becomes the concept of albums again? - We have to come up with all sorts of unique id generation to identify photos, as without the boundaries of albums, you can have file name collisions when uploading two photos, with same file DSC0001.jpg when they actually two different photos. - I'm also not sure how big the impact on the user experience and in the UI itself. I'm also not sure if we can't really still provide all tag support on top of current album based gallery. Having said that, if others think this has more flexibility and would be a better approach... and if someone is willing to help on the UI side, I'm willing to start moving to that direction on the REST branch. > Image Operations > > – Retrieve a specific image from gallery > > GET http://localhost:8080/photark/gallery/dsc123.jpg > > – Add new image to gallery > > POST http://localhost:8080/photark/gallery/dsc123.jpg > > – Update new image to gallery > > PUT http://localhost:8080/photark/gallery/dsc123.jpg > > – Delete an image from gallery (this should consequently remove the > image reference from all albums) > > DELETE http://localhost:8080/photark/gallery/dsc123.jpg > > – Retrieve a list of image references for an album > > GET http://localhost:8080/photark/gallery/<album>/images > > – Add new image reference to album > > POST http://localhost:8080/photark/gallery/<album>/dsc123.jpg > > – Add an image reference from album > > DELETE http://localhost:8080/photark/gallery/<album>/dsc123.jpg > > Note: with this APIs the user won't be able to be aware of pictures if > they are not in an album, but if we want to, we can also add > > – Retrieve images from gallery > > GET http://localhost:8080/photark/gallery/images > > If images are uploaded directly to "gallery", this proposal won't work and we need to handle collisions with something like : GET http://localhost:8080/photark/gallery/124324223 where 124324223 is a unique (and possible short) identifier for dsc123.jpg > Should we use http://localhost:8080/photark/gallery or > http://localhost:8080/photark/gallery/albums/ > > +1 for http://localhost:8080/photark/gallery/albums/ > > Do we ever need to retrieve a list of albums with full data ? > > Do you see any reason to not to? > If we still have albums, I believe that the most common scenario is that you retrieve a list of albums, and then show the contents of a given album. Not sure if you want to have the ability to return the content of all albums, which might be big. Having said that, it should be pretty easy to provide another endpoint to output the full content of the album, but it probably should not be the default behavior. -- Luciano Resende http://people.apache.org/~lresende http://twitter.com/lresende1975 http://lresende.blogspot.com/
