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
