Setting up a headless 0.8 REST server

[Hans Granqvist <ha...@granqvist.com>]

Hi all

One of the things that excite me about the RESTful API of 0.8 is
that I can implement a headless service and in a sense outsource
all the webapp UI, gadget rendering, etc., to other services.

It seems though that the spec(*) doesn't like that. From section 4:

  "Containers MUST be an OAuth Core 1.0 Service Provider (a
  web application that allows access via OAuth)"

Am I reading this wrong, or does this mean that there simply is no
way to implement the REST APIs without also implementing some
sort of UI rendering and redirect to obtain user authorization?

I guess you can argue that if you're a Container, then, yes, you should
implement the UI, but in an ideal world, I'd like to set up just a web
service that responds to a fixed set of requests and not worry at all
about the hard part of gadget rendering, and rather put this onus on
the client. Is this a pipe dream? ;) Why should a primary server-to-
server REST API implementation have to deal with webapps?

Thanks,
Hans

(*) http://code.google.com/apis/opensocial/docs/0.8/restfulspec.html

Re: Setting up a headless 0.8 REST server

[Hans Granqvist <ha...@granqvist.com>]

On Wed, Jul 23, 2008 at 4:05 PM, David Primmer <da...@gmail.com> wrote:
> There are ways to implement the OAuth SP that don't require the same
> server that serves resources to be the one taking credentials or
> delegation from the end user. The OAuth docs and the samples at
> OAuth.net tend to lump these together but this is not the way I see it
> happening at scale.

This was always a maddening OAuth restriction to me: that the producer and
consumer of the token had to be the same entity.  So it's good Shindig forges
ahead here.

> The OAuth SP code in shindig right now does not
> have any of these UI components and if it ever does, they will
> probably be very simple examples. This has been discussed (using a
> SAML redirect in the middle of the OAuth flow) on the oauth google
> group a few times.

SAML? A SOAP based standard? The nerve!  ;)

Anyway, I'll check the mailing lists for more info though. Thanks!

Hans

Re: Setting up a headless 0.8 REST server

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

There are ways to implement the OAuth SP that don't require the same
server that serves resources to be the one taking credentials or
delegation from the end user. The OAuth docs and the samples at
OAuth.net tend to lump these together but this is not the way I see it
happening at scale. The OAuth SP code in shindig right now does not
have any of these UI components and if it ever does, they will
probably be very simple examples. This has been discussed (using a
SAML redirect in the middle of the OAuth flow) on the oauth google
group a few times.

davep

On Wed, Jul 23, 2008 at 3:12 PM, Hans Granqvist <ha...@granqvist.com> wrote:
> Hi all
>
> One of the things that excite me about the RESTful API of 0.8 is
> that I can implement a headless service and in a sense outsource
> all the webapp UI, gadget rendering, etc., to other services.
>
> It seems though that the spec(*) doesn't like that. From section 4:
>
>  "Containers MUST be an OAuth Core 1.0 Service Provider (a
>  web application that allows access via OAuth)"
>
> Am I reading this wrong, or does this mean that there simply is no
> way to implement the REST APIs without also implementing some
> sort of UI rendering and redirect to obtain user authorization?
>
> I guess you can argue that if you're a Container, then, yes, you should
> implement the UI, but in an ideal world, I'd like to set up just a web
> service that responds to a fixed set of requests and not worry at all
> about the hard part of gadget rendering, and rather put this onus on
> the client. Is this a pipe dream? ;) Why should a primary server-to-
> server REST API implementation have to deal with webapps?
>
> Thanks,
> Hans
>
> (*) http://code.google.com/apis/opensocial/docs/0.8/restfulspec.html
>

Re: Setting up a headless 0.8 REST server

[Kevin Brown <et...@google.com>]

On Wed, Jul 23, 2008 at 3:12 PM, Hans Granqvist <ha...@granqvist.com> wrote:

> Hi all
>
> One of the things that excite me about the RESTful API of 0.8 is
> that I can implement a headless service and in a sense outsource
> all the webapp UI, gadget rendering, etc., to other services.
>
> It seems though that the spec(*) doesn't like that. From section 4:
>
>  "Containers MUST be an OAuth Core 1.0 Service Provider (a
>  web application that allows access via OAuth)"
>
> Am I reading this wrong, or does this mean that there simply is no
> way to implement the REST APIs without also implementing some
> sort of UI rendering and redirect to obtain user authorization?


If the authorization flow was done by an external service, that's fine, but
you can't support OAuth without ...auth. That would just be "O", and that
doesn't end well.

If you're just supporting read-only access to the data, you could probably
get away with not having any auth at all.


>
>
> I guess you can argue that if you're a Container, then, yes, you should
> implement the UI, but in an ideal world, I'd like to set up just a web
> service that responds to a fixed set of requests and not worry at all
> about the hard part of gadget rendering, and rather put this onus on
> the client. Is this a pipe dream? ;) Why should a primary server-to-
> server REST API implementation have to deal with webapps?
>
> Thanks,
> Hans
>
> (*) http://code.google.com/apis/opensocial/docs/0.8/restfulspec.html
>