>
> 1.) Instead of sending a PUT to
> /resource1/{r1_identifier}/resource2/{r2_identifier}, you could try
> sending a PUT to /resource1/{r1_identifier}/resource2/ with
> {r2_identifier} as the entity body?
It's not reversible for a many to many relationship unless
/resource1/{r1_identifier}/resource2/ represents the entire collection. If
I PUT "wings" into /resource1/birds/resource2 and later PUT "feet" into
/resource1/birds/resource2, this semantic indicates that "feet" overwrite
"wings" and that a subsequent GET should return "feet," not "wings, feet".
2.) Send a default entity body so the request goes through.
I think this is the way to go, honestly, even if it lacks the purity Rhett
is looking for.
My interpretation of the spec is that an entity is required for a PUT
I always thought so, but couldn't find a clear citation thereof, which
surprises me greatly. This kind of contravenes one of my core understanding
about what "existence" means for a resource. If anyone is in conversational
contact with any of the HTTP/1.1 authors, I'd be academically interested in
their intent on this point!
In reality, I think the issue is that lots of implementors and
implementations have interpreted it the same way as Restlet, so for all
intents and purposes it's probably a bad idea to introduce an API that
relies on PUT of empty entities.
Rhett, I looked back at some of our projects using this design and found
that in all cases the link attributes are /important./ So maybe if you
define the entity body as containing a list of link attributes (which may be
empty for now; <link-attributes/>) you may find that instead of being an ad
hoc workaround, this is a good forward-looking step for future evolution of
your solution. Unless your understanding of the problem domain indicates
that there will never be any attributes associated with such a linkage.
- Rob
