Hi and welcome to the updated version of Decapod's client-server communication interface!
To make them more intuitive, the URLs might look as: /images/ - a collection of all resources, currently known as model. JSON object (contains a list of objects, containing paths to image files). /images/0/ - a collection of all resources for a given image (full, thumb, fixed). JSON object (contains paths to each of the three image files). /images/0/full, /images/0/thumb, /images/0/fixed - each one corresponds to an image resource (image/jpeg). These will use the standard HTTP methods, which can now be intuitively mapped to an action (e.g. POST /images/0/fixed will create a new resource - dewarped image). Will be happy to discuss these tomorrow. Greetings, Boyan 2010/1/26 Boyan Sheytanov <[email protected]> > Hi Colin et al! > > As I finished the client-side UI for the Fix image functionality > (FLUID-3478 now resolved), I moved on to the server-side. Before writing a > script for fixing images, I thought it would be good to devise the URI API > so that we can finalize it and document it (would be useful to Thomas' team > as well). Having spent some time thinking over, reading and recalling > RESTful concepts, I am now at a fork in the road to RESTfulness. > > The left path is kind of tricky - it doesn't make the application RESTful, > only makes the URLs more resource oriented (i.e. we will have DELETE > http://www.myDecapodServer.com/images/13 instead of GET > http://www.myDecapodServer.com/delete?fileIndex=13). The right road leads > us to internal peace by moving the model from the Capture component to the > server and keeping only the currently selected image in the client, thus > conforming to all REST constraints. I'm inclined to take the right turn so > here's a detailed description of where it leads: > > The model is kept server-side (model = an array of items, each item having > a path to the full-sized, thumbnail, and dewarped images). Each item in the > model is the representation (in REST terms) of a resource. Each resource can > be accessed by a unique ID (the index it has in the model). The only state > kept in the client is the index of the currently selected image. Then, we > can have the following API (all of the URIs are prefixed by the server > name): > > POST /images/ - takes a new picture, generates a thumbnail, saves both to > the file system, returns an id (index in the model). > PUT /images/ - generates PDF, returns path to it. > GET /images/3 - returns the representation of an image. That is an object > with fullImage, thumbImage and fixedImage properties. > DELETE /images/3 - deletes the image at the specified index in the model. > POST /images/3 - recaptures an image, returns new representation. > PUT /images/3 - fixes image, returns new representation. > > Pros - using only standard HTTP methods, all paths represent resources. > Cons - actions not intuitively mapped to methods (this is not standard CRUD > as in many RESTful applications), not easily extensible if a lot more > actions come up in the future. > > Thought of something like POST /images/0/fix, etc, but didn't like it > because paths do not always represent a resource. Might reconsider it > though. > > Does any of the above make sense? I'd appreciate your answers (or questions > - I feel I didn't express my ideas well enough). > > Greetings, > > Boyan >
_______________________________________________________ fluid-work mailing list - [email protected] To unsubscribe, change settings or access archives, see http://fluidproject.org/mailman/listinfo/fluid-work
