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
