[0.8.1] Get supportedFields through the RESTful API

[Chris Chabot]

Since you can specify which fields to fetch in a GET /people/... call,
you should also have a method of finding out what fields are available
on the container.

The JavaScript API already has support for this but we are lacking a
RESTful counterpart.

The current suggestion is to add a /people/@supportedFields and /
activities/@supportedFields to the RESTful specification, which
returns the supported fields in an atom / json structure.

So far there has been no negative feedback on this proposal, so i
think we're be ready to vote for this addition to the specification.

[John Hjelmstad]

+1 on the concept, though I would like to see at least a draft of the actual text to be added to the spec. Ideally as a .patch, but in-mail would do.

[Cassie]

+1

[Ropu]

+1

On Tue, Jul 22, 2008 at 1:34 PM, Cassie <do...@google.com> wrote:

+1

g

--
.-. --- .--. ..-
R o p u

[Paul Lindner]

I like the concept. However we should not ignore the work done by
Lane that shows how to report OpenSocial capabilities:

http://groups.google.com/group/opensocial-and-gadgets-spec/browse_thread/thread/728de8e1a42553d2

For example it might be nice to surface the views that are supported
by a container etc. (this also has implications for the JS/REST
feature parity)

Paul Lindner
plin...@hi5.com

[Chris Chabot]

Hey Paul, thanks for bringing that up, i followed that thread with a
lot of attention at the time, but had almost forgotten about it too
since its been a while :)

I think that now we have a RESTful interface, and a method (XRDS) to
learn where the URL's are, it's probably easier and more consistent to
retrieve the container information that way.

As far as the extra information goes, it brings up the interesting
point of feature parity indeed. What is your suggestion on how we
should handle this?

Maybe add a REST service that returns the container information
(supported fields, views, (?)) in a single request? Would love to hear
your input!

-- Chris

[chabotc]

We currently have 4 +1 votes for this proposal so could use one more
before we reach our (self imposed) deadline.

Also Paul brought up an interesting point about exposing more then
just the supported fields, is anyone interested in including that in
the 0.8.1 revision or adjusting the proposal to allow this to be added
at a later date ?

On Jul 22, 9:29 pm, Chris Chabot <chab...@xs4all.nl> wrote:
> Hey Paul, thanks for bringing that up, i followed that thread with a  
> lot of attention at the time, but had almost forgotten about it too  
> since its been a while :)
>
> I think that now we have a RESTful interface, and a method (XRDS) to  
> learn where the URL's are, it's probably easier and more consistent to  
> retrieve the container information that way.
>
> As far as the extra information goes, it brings up the interesting  
> point of feature parity indeed. What is your suggestion on how we  
> should handle this?
>
> Maybe add a REST service that returns the container information  
> (supported fields, views, (?)) in a single request? Would love to hear  
> your input!
>
>         -- Chris
>
> On Jul 22, 2008, at 8:56 PM, Paul Lindner wrote:
>
>
>
> > I like the concept.  However we should not ignore the work done by
> > Lane that shows how to report OpenSocial capabilities:
>

> >http://groups.google.com/group/opensocial-and-gadgets-spec/browse_thr...

>
> > For example it might be nice to surface the views that are supported
> > by a container etc.  (this also has implications for the JS/REST
> > feature parity)
>
> > On Jul 22, 2008, at 1:54 AM, Chris Chabot wrote:
>
> >> Since you can specify which fields to fetch in a GET /people/...  
> >> call,
> >> you should also have a method of finding out what fields are  
> >> available
> >> on the container.
>
> >> The JavaScript API already has support for this but we are lacking a
> >> RESTful counterpart.
>
> >> The current suggestion is to add a /people/@supportedFields and /
> >> activities/@supportedFields to the RESTful specification, which
> >> returns the supported fields in an atom / json structure.
>
> >> So far there has been no negative feedback on this proposal, so i
> >> think we're be ready to vote for this addition to the specification.
>
> > Paul Lindner

> > plind...@hi5.com

[John Panzer]

+1 to at least a list of supported fields (but we do need a spec diff...)

--
John Panzer (http://abstractioneer.org)

[Paul Lindner]

+1 on the proposed format. It will be sufficient for this use case
and it includes json formatted output. Lane's introspection document
was more general purpose and might still find a place in a future
specification.

Paul Lindner
plin...@hi5.com

[chabotc]

This proposal has recieved 6 +1 votes, and has thus been accepted for
the 0.8.1 specification revision.

It was noted we should think about expanding this construction in the
future to expose more container information, but this has been
postponed to another spec revision.