[Decapod] RESTful API

Boyan Sheytanov boyan.sheytanov at asteasolutions.com
Wed Jan 27 14:55:57 UTC 2010


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 <boyan.sheytanov at asteasolutions.com>

> 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
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://fluidproject.org/pipermail/fluid-work/attachments/20100127/435a8a2d/attachment.html>


More information about the fluid-work mailing list