I agree filtering on a single entity is silly:
But under the table of section 7.9 of the spec at
http://opensocial-resources.googlecode.com/svn/spec/draft/REST-API.xml
"
/people/@me/@self?
filter...@friends&filterOp=contains&filterValue=<someUserId>
This will return nothing if the other ID is not a friend, the current
user if the two are friends. filterValue may take a specific person
identifier of @owner or @viewer.
"
Which implies that filtering on the *single* @me/@self entity is the
way to find if the current user is friends with the specified user.
Back in the early thread, (about a week ago) I think I said the spec
looked odd.
This is where the original URL that started this thread comes from.
---------------------------
So a question for you, Chris,
should /people/@me/@self respond to filtering?
Ian
On 13 Feb 2009, at 12:58, Chris Chabot wrote:
There's really no need to assume anything, /people/@me/@self is a
single
entity and can never be more then one result.
Hence filtering is a bit silly, what exactly would you want to
filter on,
what would be the use-case for wanting to know a viewer *only if
<condition>* ?
The only situation in which /people/@me/@self returns an error is
when your
using 2 legged OAuth (or anonymous read access is allowed), in which
case
the securityToken's getViewer() will throw an exception since @me
can't be
resolve to an ID in those situations.
In every other situation, getViewer() returns an id, which is used to
resolve @me/@self to a single user record, which is not really
filterable,
since filtering only makes sense on collections, right?
On Fri, Feb 13, 2009 at 1:52 PM, Ian Boston <[email protected]> wrote:
Can I unwind this a little please.
The original patch for 904 was to introduce a change the SPI for
getPerson
with filtering.
I argued that getPeople already provides the filtering so there was
no need
for a SPI change.
Ben pointed out that the REST response would then be a collection
which
exposed a tension in the spec.
Did I get that right?
Lets assume for a moment that the output of the current servlet *is*
correct (ie not a collection)
having called getPeople check the response and emit a 404 if there
are 0
entries and the only entry if there is 1 (there should not be more
than 1 as
a result of the filter). Obviously the Future needs to be wrapped to
evaluate this when its needed and not before.
Does that make sense?
I think if they current servlet is not correct then that needs
sorting out
separately, but I see emails on this thread stacking up faster than
I can
type or think or answer the phone.
Ian
On 13 Feb 2009, at 12:36, Chris Chabot wrote:
On Fri, Feb 13, 2009 at 1:27 PM, Ben Smith <[email protected]>
wrote:
On 13 Feb 2009, at 12:09, Chris Chabot wrote:
'@self' is not a collection by any definition of the word, it's a
single
object, hence the lack of the collection (and the lack of
filtering,
there
is only one 'self' and that's the viewer :)
The same goes for activities, a query on /activities/@me/@self
returns a
collection of activities (since it can contain 0, 1 or many
results),
however /activities/@me/@self/<activityId> can only return 0 or 1
results,
so it returns an activity record and not a RestfulCollection.
But that's not what the spec says should happen: If the request is
specifically for a single contact (e.g. because the request
contains
Additional Path Information like /@me/@all/{id} or /@me/@self),
then
entry
MUST be an object containing the single item returned (i.e.
"entry": [ {
/*
first item */ } ] and "entry": { /* only item */ } respectively).
Unless I'm reading it wrong, /@me/@self should still return
<response><entry><person></person></entry></response>
There are 2 parts to the definition:
1) if the request could possibly return multiple items (as is
normally the
case), this value MUST always be an array of results, even if there
happens
to be 0 or 1 matching results
if something could return multiple entries it has to be a
collection,
however /@me/@self is a single entry, so this doesn't apply here
2) If the request is specifically for a single contact (e.g.
because the
request contains Additional Path Information like /@me/@all/{id} or
/@me/@self), then entry MUST be an object containing the single item
returned
So if the query is for /@me/@self it *MUST be a single entry.*
I think your either confused and consfusing /@me/@self with /@me/
@all
(which
is an PortableContacts way of saying /@me/@friends), or your a
believer in
possessions and believe that our definition of a person being a
singular
entity is wrong and the spec should be changed to allow for multiple
spirits
and/or demons in one physical body. (And i truly hope that is not
what
your
suggesting :)
I agree that filter...@friends&filterValue=<userId> is confusing,
but
filterBy=id&filterValue=<userId> would surely remove all people
that do
not
have <userId> as their userId! I guess you really want a filterBy
AND
filterOn (or something), or explicitly name filterValue to
filterUserIdValue
(or something).
Filtering on /@me/@self is confusing, since it's only one record,
what
would
you want to filter on?
