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.
If there are more creative designs out there, I'm sure someone will
volunteer one!
I picked over RFC 2616 and think your interpretation is correct. Neither
9.6 (PUT), nor 4.3 (Message Body), nor 7.2 (Entity Body) preclude omitting
the entity in methods that typically have an entity. They forbid the
presence of an entity in requests and responses that should not have one (
e.g. response to HEAD), but do not require one in other cases.
Given that reading, if Restlet itself is returning the 400, that's probably
worth filing as a bug. But I would be willing to bet, though, that the use
of empty entities on PUT will break assumptions in some of the client and
server connectors for Restlet, even if Restlet internally allows it.
In actual use cases where I have employed this idiom, there was meaningful
information associated with each link resource, such as who created the link
and/or the nature of the relationship; because the PUT and GET operations
created and consumed this information, I did not run into the empty entity
problem.
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?
- Rob
