Hi Rob,
On Jan 14, 2008, at 12:13 AM, Rob Heittman wrote:
I can't fault your design given your constraints. I think the
general concept: identifying links with hierarchical URIs descending
from the URI of each linked object, is at least a common idiom if
not an established pattern. I have both seen and used this style a
number of times.
I have also seen the link collection represented in the aggregate as
a single resource, e.g. /resource1/{r1_identifier}/resource2/links
-- with a JSON, XML, text, etc. representation listing the complete
set of all linkages. I believe this can be efficient for
enumerating linkages if their quantities fall within a certain
range, but doesn't work very well if you need to allow clients to
add and remove links individually.
I've considered a POSTable collection like you describe (actually,
without the "links" part -- just /resource1/{r1_identifier}/
resource2), but I prefer the GET/PUT approach I outlined before
because there's no uncertainty about what the eventual URI will be, so
it seems unnecessary to have the client construct a throwaway
representation that just has r2_identifier in it.
Even if there's no such information for-real, would it work to PUT
and GET a trivial representation, e.g. type text/plain "+", for each
link resource, to work around the undesirable empty entity behavior?
That's what I'm doing for the moment, and it works well enough. If
possible I'd prefer not to publish the API that way -- it seems sort
of arbitrary.
Thanks for your reply,
Rhett
