Re: proposal for an implementation of OpenSocial RESTful API

[David Primmer <da...@gmail.com>]

I'd like to propose that we drop the -c from json-c in the Restful API
spec and just call our output format json.

The spec is nearing completion for 0.8 and we're about to submit a
patch that begins to enable json processing for the api server.
Currently the patch configures the server according to the spec, with
query parameter of "format=json-c" that is the default for the server.

The primary reason for the "-c" suffix, as I understand it, is the
underlying java framework Abdera has some prior art, in an extension
module called 'json' that responds to requests with "format=json" and
produces an atom-like json representation. I feel like we should
explicitly replace this format with the speicialized json format in
the rest api spec. If users of the java server wanted to turn on
abdera's json extension, there would be a conflict. I don't know how
this would be resolved and I'm hoping James Snell, the author, chimes
in here.

To this point, the shindig implementation has not included this
extension and it probably never will. I don't feel like a small
implementation detail in one of the libs of one of the languages
should should impact the spec this way. If anything, the Abdera json
extension, if used, should respond and be suffixed something like
json-atom or json-snell. ;-)

davep

davep

On Wed, Apr 9, 2008 at 11:56 AM, Jun Yang (杨骏) <jy...@google.com> wrote:
> Hi all.
>
> We would like to propose an implementation for "A modest proposal for an
> OpenSocial RESTful API".
>
> We propose the following:
>
> Use Apache Abdera as the basis of the reference server implementation
> Add a JsonCParser to support input in JSON-c format (JSON-c for compact JSON
> format as specified in the API spec, not a new MIME type)
> Add a JsonCWriter to support output in JSON-c format
> Add an OpenSocial API (Person, Activity and AppData, Java version under
> org.apache.shindig.social.opensocial) adapter to integrate with existing API
> implementation and keep the same interface on the backend and the client
> for the following reasons:
>
> The RESTful API proposal supports a clean and natural JSON format (JSON-c)
> as well as AtomPub.  Apache Abdera is an open source reference
> implementation of AtomPub that offers most of the functionality we need.
> Reusing it seems to be natural choice
> Abdera already supports input in Atom.  We need to add support for input in
> JSON-c
> Abdera already supports output in Atom (as well as a JSON format).  We need
> to add support for output in JSON-c
> Abdera's support for adapters that translate from a foreign data format and
> protocol into its Feed Object Model (FOM) comes handy to support existing
> data sources such as relational databases and existing implementation of
> OpenSocial APIs.  Existing OpenSocial APIs are very close to Atom's model
> and can be adapted easily
> We have includes two diagrams as illustration of the architecture of the
> proposed implementation.  Diagram 1 shows the generic architecture.  Those
> components in italics are to be written.  Diagram 2 shows the use of two
> adapters, iBATIS (existing in Abdera) to integrate with relational
> databases, and OpenSocial API adapter (to be written), to integrate with
> existing OpenSocial backend.
>
> Please review and comment.  Thanks!
>
> Vasu Nori and Jun Yang

Re: proposal for an implementation of OpenSocial RESTful API

[John Panzer <jp...@google.com>]

+1 (actually before I saw this I had made this change in the very latest
spec, based on prior discussion and no -1's...)

2008/5/5 David Primmer <da...@gmail.com>:

> I'd like to propose that we drop the -c from json-c in the Restful API
> spec and just call our output format json.
>
> The spec is nearing completion for 0.8 and we're about to submit a
> patch that begins to enable json processing for the api server.
> Currently the patch configures the server according to the spec, with
> query parameter of "format=json-c" that is the default for the server.
>
> The primary reason for the "-c" suffix, as I understand it, is the
> underlying java framework Abdera has some prior art, in an extension
> module called 'json' that responds to requests with "format=json" and
> produces an atom-like json representation. I feel like we should
> explicitly replace this format with the speicialized json format in
> the rest api spec. If users of the java server wanted to turn on
> abdera's json extension, there would be a conflict. I don't know how
> this would be resolved and I'm hoping James Snell, the author, chimes
> in here.
>
> To this point, the shindig implementation has not included this
> extension and it probably never will. I don't feel like a small
> implementation detail in one of the libs of one of the languages
> should should impact the spec this way. If anything, the Abdera json
> extension, if used, should respond and be suffixed something like
> json-atom or json-snell. ;-)
>
> davep
>
> davep
>
> On Wed, Apr 9, 2008 at 11:56 AM, Jun Yang (杨骏) <jy...@google.com> wrote:
> > Hi all.
> >
> > We would like to propose an implementation for "A modest proposal for an
> > OpenSocial RESTful API".
> >
> > We propose the following:
> >
> > Use Apache Abdera as the basis of the reference server implementation
> > Add a JsonCParser to support input in JSON-c format (JSON-c for compact
> JSON
> > format as specified in the API spec, not a new MIME type)
> > Add a JsonCWriter to support output in JSON-c format
> > Add an OpenSocial API (Person, Activity and AppData, Java version under
> > org.apache.shindig.social.opensocial) adapter to integrate with existing
> API
> > implementation and keep the same interface on the backend and the client
> > for the following reasons:
> >
> > The RESTful API proposal supports a clean and natural JSON format
> (JSON-c)
> > as well as AtomPub.  Apache Abdera is an open source reference
> > implementation of AtomPub that offers most of the functionality we need.
> > Reusing it seems to be natural choice
> > Abdera already supports input in Atom.  We need to add support for input
> in
> > JSON-c
> > Abdera already supports output in Atom (as well as a JSON format).  We
> need
> > to add support for output in JSON-c
> > Abdera's support for adapters that translate from a foreign data format
> and
> > protocol into its Feed Object Model (FOM) comes handy to support
> existing
> > data sources such as relational databases and existing implementation of
> > OpenSocial APIs.  Existing OpenSocial APIs are very close to Atom's
> model
> > and can be adapted easily
> > We have includes two diagrams as illustration of the architecture of the
> > proposed implementation.  Diagram 1 shows the generic architecture.
>  Those
> > components in italics are to be written.  Diagram 2 shows the use of two
> > adapters, iBATIS (existing in Abdera) to integrate with relational
> > databases, and OpenSocial API adapter (to be written), to integrate with
> > existing OpenSocial backend.
> >
> > Please review and comment.  Thanks!
> >
> > Vasu Nori and Jun Yang
>
> --~--~---------~--~----~------------~-------~--~----~
> You received this message because you are subscribed to the Google Groups
> "OpenSocial and Gadgets Specification Discussion" group.
> To post to this group, send email to
> opensocial-and-gadgets-spec@googlegroups.com
> To unsubscribe from this group, send email to
> opensocial-and-gadgets-spec-unsubscribe@googlegroups.com
> For more options, visit this group at
> http://groups.google.com/group/opensocial-and-gadgets-spec?hl=en
> -~----------~----~----~----~------~----~------~--~---
>
>

RE: proposal for an implementation of OpenSocial RESTful API

[Paul Walker <pw...@myspace.com>]

Absolutely +1...thx JP for listening.

-----Original Message-----
From: opensocial-and-gadgets-spec@googlegroups.com [mailto:opensocial-and-gadgets-spec@googlegroups.com] On Behalf Of David Primmer
Sent: Monday, May 05, 2008 6:01 PM
To: shindig-dev@incubator.apache.org
Cc: opensocial-and-gadgets-spec@googlegroups.com
Subject: Re: proposal for an implementation of OpenSocial RESTful API

I'd like to propose that we drop the -c from json-c in the Restful API
spec and just call our output format json.

The spec is nearing completion for 0.8 and we're about to submit a
patch that begins to enable json processing for the api server.
Currently the patch configures the server according to the spec, with
query parameter of "format=json-c" that is the default for the server.

The primary reason for the "-c" suffix, as I understand it, is the
underlying java framework Abdera has some prior art, in an extension
module called 'json' that responds to requests with "format=json" and
produces an atom-like json representation. I feel like we should
explicitly replace this format with the speicialized json format in
the rest api spec. If users of the java server wanted to turn on
abdera's json extension, there would be a conflict. I don't know how
this would be resolved and I'm hoping James Snell, the author, chimes
in here.

To this point, the shindig implementation has not included this
extension and it probably never will. I don't feel like a small
implementation detail in one of the libs of one of the languages
should should impact the spec this way. If anything, the Abdera json
extension, if used, should respond and be suffixed something like
json-atom or json-snell. ;-)

davep

davep

On Wed, Apr 9, 2008 at 11:56 AM, Jun Yang (杨骏) <jy...@google.com> wrote:
> Hi all.
>
> We would like to propose an implementation for "A modest proposal for an
> OpenSocial RESTful API".
>
> We propose the following:
>
> Use Apache Abdera as the basis of the reference server implementation
> Add a JsonCParser to support input in JSON-c format (JSON-c for compact JSON
> format as specified in the API spec, not a new MIME type)
> Add a JsonCWriter to support output in JSON-c format
> Add an OpenSocial API (Person, Activity and AppData, Java version under
> org.apache.shindig.social.opensocial) adapter to integrate with existing API
> implementation and keep the same interface on the backend and the client
> for the following reasons:
>
> The RESTful API proposal supports a clean and natural JSON format (JSON-c)
> as well as AtomPub.  Apache Abdera is an open source reference
> implementation of AtomPub that offers most of the functionality we need.
> Reusing it seems to be natural choice
> Abdera already supports input in Atom.  We need to add support for input in
> JSON-c
> Abdera already supports output in Atom (as well as a JSON format).  We need
> to add support for output in JSON-c
> Abdera's support for adapters that translate from a foreign data format and
> protocol into its Feed Object Model (FOM) comes handy to support existing
> data sources such as relational databases and existing implementation of
> OpenSocial APIs.  Existing OpenSocial APIs are very close to Atom's model
> and can be adapted easily
> We have includes two diagrams as illustration of the architecture of the
> proposed implementation.  Diagram 1 shows the generic architecture.  Those
> components in italics are to be written.  Diagram 2 shows the use of two
> adapters, iBATIS (existing in Abdera) to integrate with relational
> databases, and OpenSocial API adapter (to be written), to integrate with
> existing OpenSocial backend.
>
> Please review and comment.  Thanks!
>
> Vasu Nori and Jun Yang

--~--~---------~--~----~------------~-------~--~----~
You received this message because you are subscribed to the Google Groups "OpenSocial and Gadgets Specification Discussion" group.
To post to this group, send email to opensocial-and-gadgets-spec@googlegroups.com
To unsubscribe from this group, send email to opensocial-and-gadgets-spec-unsubscribe@googlegroups.com
For more options, visit this group at http://groups.google.com/group/opensocial-and-gadgets-spec?hl=en
-~----------~----~----~----~------~----~------~--~---