Hey, We talked about this in person at the weekly Decapod meeting today, but here's a quick response below.
On 2010-01-27, at 9:55 AM, Boyan Sheytanov wrote: > 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). I think this is the right path. This mapping is clear, simple, and corresponds directly to real resources we manipulate on the client and the server. Nice work! This design has one compromise that I can think of, but it doesn't bother me much. In a sense, one might find it confusing that when we POST to /images/0/fixed, the body of that request isn't the fixed image itself. This request actually triggers the fixing process and the creation of the resource, but I think it fits the spirit of REST nonetheless. Boyan, go for it! Let's modify the current dserver.py to support this style of RESTfulness. As Decapod grows, I expect this will vastly simplify the client-side code as a result, and make it easier to build other types of interfaces or extensions on to the system. +1 Colin --- Colin Clark Technical Lead, Fluid Project http://fluidproject.org _______________________________________________________ fluid-work mailing list - [email protected] To unsubscribe, change settings or access archives, see http://fluidproject.org/mailman/listinfo/fluid-work
