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