On 6/2/09 10:47, Ian Boston wrote:
Sorry, yes you are right, re-reading the spec more carefully.
Does that change the call to getPeople() or just the underlying
implementation.
Should just be the underlying implementation. All the necessary
information is in the method signature.
I would rather not change the getPerson() signature when correct use
of getPeople() even with a collection of 1 has the required
functionality.
I think however what is confusing is the layered functionality of the
getPeople query, and the overlaid meaning of /people/@me/@self to mean
the object in on instance and the existence of a friend in another.
To my mind /people/@me/@friends/{friendGuid} which returns the friend
if the fiend is a friend, and a blank or 404 if not. But that is a
spec issue.
The problem is, the response from getPeople will not suffice (I hoped it
would) as it returns a RestfulCollection:
<response><entry><person></person></entry></response> while getPerson()
just returns a Person: <response><person></person></response>. While I
have my own personal feelings on the spec's format, we need to honor the
difference in response between getPerson requests (/people/@me/@self and
/people/@me/@friends/{friendGuid}) and getPeople requests
(/people/@me/@friends...).
Is it worth bringing up on the spec list or are the URL semantics Ok?
There are problems with the semantics, but we can simply deal with this
specific problem by passing CollectionOptions to getPerson() and have
the implementation deal with it. Any other solution requires changing
the spec or adding more complexity to PersonHandler.
If you think it's worth bringing up on the spec list for a longer-term
resolution, then I'm happy to.
Still might be worth renaming CollectionOptions.
Ian
Ben
