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: 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 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? Best Regards, Adriano Crestani Campos On Wed, Jun 9, 2010 at 6:16 PM, Luciano Resende <[email protected]> wrote: > > On Sun, Jun 6, 2010 at 10:35 AM, Luciano Resende <[email protected]> wrote: > > On Wed, Jun 2, 2010 at 9:13 PM, Henry Saputra <[email protected]> > > wrote: > >> +1 for making Album and Gallery as separate object model. > >> > >> I think this is inline with questions from others regarding Album and > >> Gallery SCA services act as creator, object model, and service providers. > >> > >> -Henry > >> > >> > >> On Mon, May 31, 2010 at 5:07 PM, Luciano Resende > >> <[email protected]>wrote: > >> > >>> On Sun, May 16, 2010 at 11:22 AM, Luciano Resende <[email protected]> > >>> wrote: > >>> > I'd like to start working on defining a more robust API to access > >>> > photoArk galleries, I'm planning to start by creating a new module > >>> > (most likely a copy of current photark module) to avoid disrupting the > >>> > current web application. I'd start by applying REST with JSON as the > >>> > default wire format, and once we are ok with the new API, we could > >>> > start migrating the existent app to use this new API. > >>> > > >>> > Thoughts ? > >>> > > >>> > >>> > >>> I have started playing with a REST API for PhotArk at my sandbox [1]. > >>> > >>> I have started by introducing a clear separation of Model and > >>> Services, and you can see that I created things like Gallery, Album > >>> and Image as pure model objects. This will makes things clear and > >>> improve performance by allowing more atomic client/server > >>> communications with the Gallery/Album services. > >>> > >>> The second area is applying REST and Hypermedia principles to our API, > >>> and the idea is that client (such as our UI) would interact with the > >>> PhotArk gallery treating it as resources, and a call to retrieve > >>> > >>> GET http://localhost:8085/gallery > >>> > >>> would get a response similar to : > >>> > >>> { > >>> "albums": [ > >>> { > >>> "ref": "http://localhost:8080/gallery/album1";, > >>> "name": "Album 1", > >>> "coverImageRef": null > >>> }, > >>> { > >>> "ref": "http://localhost:8080/gallery/album2";, > >>> "name": "Album 2", > >>> "coverImageRef": null > >>> } > >>> ] > >>> } > >>> > >>> Note that this initial response has all the information to build the > >>> "gallery index" with a list of all available albums, and also provides > >>> direct link to calling further service api to retrieve extra > >>> information (e.g the album details via album:ref attribute ). > >>> > >>> Please let me know your thoughts on this, and if people are ok with > >>> this direction, I'll start investigating what's the best way to > >>> integrate this to trunk. > >>> > >>> [1] > >>> http://svn.apache.org/repos/asf/incubator/photark/sandbox/lresende/photark-rest/ > >>> > >>> > >>> -- > > > > I'll create a new branch (photark-rest) and start to apply these > > changes in parallel to trunk to avoid breakages of the current > > functionality. > > > > > > And some thoughts on the direction being taken available at > > https://cwiki.apache.org/confluence/display/PHOTARKxWIKI/PhotArk+REST+API > > -- > Luciano Resende > http://people.apache.org/~lresende > http://twitter.com/lresende1975 > http://lresende.blogspot.com/
