Sorry, yes you are right, re-reading the spec more carefully.
Does that change the call to getPeople() or just the underlying
implementation.
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.
Is it worth bringing up on the spec list or are the URL semantics Ok?
Ian
On 6 Feb 2009, at 10:27, Ben Smith wrote:
My interpretation of /people/@me/@self?
filter...@friends&filterOp=contains&filterValue=<someUserId> seems
to be different from yours.
I understood it to mean that, as long as you are friends with
<someUserId>, then you would get the same response as a straight
call to /people/@me/@self. If, however, you are not friends, then
you would get back an empty response, as that person (you) whould
have been filtered.
To return a collection, with it's full RestfulCollection wrapper and
entries, for the same resource /people/@me/@self, if you send a
different query string, would be pretty un-RESTful.
This means that these requests have to be served by getPerson(), as
they return the single object that gets marshaled as a
<response><person>..</person></response>.
On 6/2/09 10:19, Ian Boston wrote:
Well, I am not certain that a change to the interface is required
since the handler should be calling getPeople if the
CollectionOptions are specified and then the implementation of
getPeople should be able to work out that its a friends query.
Naming, thats debatable:
One view is that the query string specifically relates to how the
collection that is returned should be filtered and sorted and not
generic options on the whole request, in which case
CollectionOptions is correct.
The other view is that this is a generic container for all request
options, which if true RequestOptions is correct.
Looking at CollectionOptions as it stands, IMHO its the former.
What could be helpful is better javadoc on the class, there is
plenty on the methods just none on the class (me bad I think).
Ian
On 6 Feb 2009, at 09:58, Ben Smith wrote:
A simple fix would be to include passing CollectionOptions to
PersonService. This would mean that the implementations can
perform the appropriate filtering. I'd also recommend renaming
CollectionOptions to RequestOptions as this would be less confusing.
I'm happy to supply a patch for this, but I'd like some steer from
the community as this will require everyone tracking the trunk to
change their interface.
On 6/2/09 09:50, Ian Boston wrote:
I think the handler is wrong.
Although the URL is pointing to the person profile of the current
user /people/@me/@self
The query is selecting the friend collection within that person
and filtering it by the supplied user ID.
ie is someUserId one of the current users friends ?
The implementation is just getting the person object and
completely ignoring the filter on the friends collection.
IMHO, the PersonHandler needs to be fixed.
Naturally the bare url should return the person, so getPerson()
is valid.
In the light of the above, the PersonService might also be
lacking, I hope to get some time soon to do some 0.9 work.
Ian
On 6 Feb 2009, at 09:10, Ben Smith wrote:
Been thinking about this some more (and talking it over with
Chico).
I can see why you need getPeople() and getPerson() methods
exposed from the PersonService, as these help adhere to the
response specifications for a single person object and a
collection of entities.
Therefore, to adhere to the spec, we need to be able to pass
down the CollectionOptions to the getPerson() function so that
the PersonService can filter the output. It would be a little
confusing to pass down 'Collection' options to something that
returns a single object, so I guess that object should be
renamed. You could split off the collection related options and
filter options, but I think that would just be annoying.
Anyone have an opinion?
Cheers,
Ben Smith
BBC
On 5/2/09 13:39, Ben Smith wrote:
I'm currently getting our service layer to comply with the
filtering options described: http://opensocial-resources.googlecode.com/svn/spec/draft/REST-API.xml#standardQueryParameters
This is particularly because I need to be able to support calls
like: /people/@me/@self?
filter...@friends&filterOp=contains&filterValue=<someUserId>
The problem is that PersonService defines a getPerson method
that does not use CollectionOptions and PersonHandler will
always call getPerson for that URL:
if (userIds.size() == 1) {
if (optionalPersonId.isEmpty()) {
if (groupId.getType() == GroupId.Type.self) {
return
personService.getPerson(userIds.iterator().next(), fields,
request.getToken());
Does anyone have a strategy for dealing with this? Would it be
such a bad thing if PersonService only exposed getPeople()?
Cheers,
Ben Smith
BBC
