[Catalyst] Actions for asserting relationships

[Peter Karman]

Bill Moseley wrote on 5/30/11 11:46 PM:
> I'm looking for more guidance wrt URLs.
> 
> Say in the music database example that tracks have a many-to-many relationship
> to albums.  A track can be associated with zero or more albums.
> 
> In the API for this we can POST, GET, PUT, and DELETE /track and /album.  But,
> what about asserting relationships between the two? 
> 
> POST /album/$album_id/add_track { track  => $track_id };
> POST /album_track { album => $album_id, track => $track_id );
> POST /album/$album_id/track/$track_id  (or /track/$track_id/album/$album_id).
> 
> The last one seems best as it allows associating other data with the
> relationship, and make DELETE make sense.
> 
> And what HTTP status code should be returned if a) the relationship is created?
> b) the relationship already exists?   I'm not sure it's important that there's a
> distinction if only need to assert that the relationship exists.  But, a 201
> really implies that the resource was created.
> 
> 
> I suppose to make this more RESTful the $track_id and $album_id should be URIs
> in that second example, but makes less sense in the first and third examples.
> 

(1) consider if/how PUT should be used instead of POST. I've found [0] to be a
helpful guide to the distinction. This seems to affect your (b) question mostly.

(2) I tend to use the 3rd URL example in my apps. I return 201 on creation and
204 on a no-op (your (b) example), or 200 on update or delete success (on DELETE
I return the deleted resource, similar to how Perl's delete() function works on
hash items).

In the end it feels to me like there are probably 1 or 2 best ways to do this
kind of thing, and I emphasize in my apps the consistency and repeatability of
the approach (and document it!) rather than fretting too much about whether I
have got it perfect.


[0] http://jcalcote.wordpress.com/2008/10/16/put-or-post-the-rest-of-the-story/
-- 
Peter Karman  .  http://peknet.com/  .  peter at peknet.com