[Web Hooks] moving apis up a (webhook) notch with a POSS service

[S Sriram]

Hi,

I've been mulling this for some time, so I thought I'd put it out there

to get ideas/comments etc.

S. Sriram

Use case

--------

Joe is cranking up his spiffy new site acme.com and wants to 

    do something with a web service

    s/do something/allow users to add events

    s/service/google calendar

    s/do something/status update

    s/service/twitter

Current scenario

-----------------

1. get api keys,

2. Wade through docs at developer.foo.com, 

3. grab oauth code libs,

4. write code,

5. test

The Problem

-----------

Steps 2-5 take time, effort and a reasonably high degree of skill and are replicated

over and over by each developer on their implementation.

The Solution

------------

ApiApps using webhooks on a POSS server

ApiApps are sinppets of hosted code that encapsulate the access to

various web apis(producers) and are made available to api consumers

via simple http calls.

As an example lets take google calendar.

If acme.com (api consumer) wants the ability to have its event be added into

its customer John's (user) google (api producer) calendar. It needs to

1. Get an oauth token from John

2. Create an api call to 'add event' to John's calendar., test etc.

This is 'high-level programming work' that needs to be done by acme.com

More importantly, besides gcal acme.com would like to connect to multiple

apis each of them requires a separate coding imperative and more 'high-level

programming man-hours' It starts to get expensive very quickly.

Now, if ApiApps provided a 'canned' microsite that 

a) used acme.com's api key

b) did the oauth on behalf of acme.com for John and google calendar

c) setup a url that when called 'added the event' to John's calendar

d) Instituted rate-limiting measures etc. and provided for an

   upgrade path out of POSS to Paid/hosting etc.

Life for acme.com would be much simpler, foo.com would see a much

greater adoption of its api/services and peace will reign on

earth :-)

How might this work.

------------------------

1. acme.com creates an account with google, gets api credentials

2. acme.com creates an account with ApiApps and submits these credentials.

3. On acme.com's website a link is placed to 

   http://www.apiapps.org/acme/google/calendar/unique-key

4. User John clicks on this link

5. apiapps receives this request and does a signed api http POST call to

   http://www.acme.com/apiapps/start with unique-key as a param.

6. acme.com/apiapps returns a JSON set of params for the google calendar

   call i.e. date, event description etc.

7. apiapps - saves this  info 

8. apiapps than gets google oauth credentials from John (saves that for

   future reference)

9. On getting John's credentials, apiapps on behalf of acme makes the

   google calendar api call/entry

10. apiapps than sends a confirmation to acme.com/apiapps/finish

11. apiapps redirects John back to acme.com

So, for acme.com to offer google calendar apiservices to its users

required

1. A onetime setup with apiapps

2. Addition of an apiapps link to website where needed

3. Writing 2 url handlers 

   - acme.com/apiapps/start

       which gets called by apiapps and returns a json payload

       detailing what needs to be done.

   - acme.com/apiapps/finish

       which gets called by apiapps with a POST containing confirmation

       detils, api call output etc.

This is 'relatively easy' programming work that can be done by a low-level

programmer.

ApiApps builds this out for google, yahoo and the major properties.

ApiApps provides a 'api adaptor library building' interface to all

other api producers, so they can build an ApiApp for their service.

Long term sustainable funding for the POSS service should be possible 

from api producers interested in seeing more rapid adoption of their

web services and with the raft of new cloud hosting services a migration

path to paid for high volume users should be possible.

--x--

--
You received this message because you are subscribed to the Google Groups "WebHooks" group.
To post to this group, send email to webh...@googlegroups.com.
To unsubscribe from this group, send email to webhooks+u...@googlegroups.com.
For more options, visit this group at http://groups.google.com/group/webhooks?hl=en.

[Daniel Parker]

I think I see what you're getting at -- I've thought about this a couple of years ago too. Sites have different authorization protocols or routines, and setting up keys and code for each one separately and explicitly is a pain.

In reference to your proposed solution:

One of the hinderances we run into is that OAuth is designed so that the Provider site must grant keys to Consumer sites, which means that it can limit and control which Consumer sites interact with it. A middle-man approach bypasses this -- for better or for worse. I for one would consider it insecure. At least, if I have a banking site, I guess I can just block ApiApps in the first place by not granting them a key.

By the way, I believe the OAuth login process verifies the host of the Consumer to match up with the consumer key being used -- so a middleman approach wouldn't work as you expect anyway.

My personal milestone for "Web 3.0" is when an app can be built ready to integrate with other sites that are not yet even built. For example, my calendar site should be able to integrate with "Carl's Calendar" website, when he decides to build it 3 years from now -- as long as his site uses appropriate standards and exposes standard discovery mechanisms. On the day "Carl's Calendar" is made live, if I have some users who want to sync scheduled events with my site, it would be immediately possible. Truth is, we don't yet have all the standards that would be necessary to build this ecosystem.

Even if you agree fully with this vision, part of the reason things move so slowly is that not many people have this vision. Every person may have a different vision of the future, and we move forward only when a large number of these visions agree on their very first step, and they work together to build a new protocol or specification. (The interesting thing is that even if you build a very good specification, it still won't take traction unless it is really the next step people are looking for, or unless you have a large corporation behind you.) That process will repeat itself over and over, with a good deal of time in between.

- daniel parker -

"You have granted me life and steadfast love, and your care has preserved my spirit." Job 10:12
"The LORD is my chosen portion and my cup . . . indeed, I have a beautiful inheritance." Psalm 16:5-6
"Give what you can ... take nothing back!"

[S Sriram]

On Wed, May 5, 2010 at 12:36 PM, Daniel Parker <dcpa...@gmail.com> wrote:

One of the hinderances we run into is that OAuth is designed so that the Provider site must grant keys to Consumer sites, which means that it can limit and control which Consumer sites interact with it. A middle-man approach bypasses this -- for better or for worse. I for one would consider it insecure. At least, if I have a banking site, I guess I can just block ApiApps in the first place by not granting them a key.

Well, the way I laid it out, acme.com would provide apiapps with it's apikeys, so apiapps would

'on behalf of acme.com'  get an oauth token, which it would only use for acme.com. In other

words apiapps would be a proxy service. the apiapps IP address, much like EC2 and AppEngine

and other IP addresses would be whitelisted by api producers. See below for domains.

 

By the way, I believe the OAuth login process verifies the host of the Consumer to match up with the consumer key being used -- so a middleman approach wouldn't work as you expect anyway.

acme.com could create an apiapps.acme.com subdomain which would CNAME to

apiapps.com, so the domain issues could be take care of.

There are no dependancies on standards etc. in the above scenario.

[Jeff Lindsay]

I think we're moving in this direction, slowly but surely. I've actually built one-off types of scenarios like the one you've described. I've envisioned a sort of ApiApps service for similar and different reasons. It'll happen eventually, but I don't see a huge reason to force it just yet. The longer you can defer these kinds of things, the easier they'll be.

--
Jeff Lindsay
http://progrium.com

[Luke Closs]

On Wed, May 5, 2010 at 1:41 PM, Jeff Lindsay <prog...@gmail.com> wrote:
> The longer you can defer these kinds of things, the easier they'll be.

Sun Tsu suggests to do the difficult things while they are easy and do
the great things while they are small.

Not sure why that seemed relevant, but maybe it will be useful. :)

Luke

[S Sriram]

Hi,

The current direction seems to be more the 'so easy your browser can do it' 

javascript apis way ala @anywhere / fb open graph etc. 

as opposed to the ApiApps way (twimlets notwithstanding)

I agree that defer-ing things makes things easier. My outline was for the

need of a POSS service, since an ApiApps like entity needs the existence of

such a service. One of the building blocks for an ApiApps like service is the

"ez oauth" piece 

i.e. a multi-service oauth-token acquiring and managing proxy.

Do any of the services/products that you have built do something like

this. Is there any work already in place for something like this??

Thanks

S. Sriram

On Wed, May 5, 2010 at 1:41 PM, Jeff Lindsay <prog...@gmail.com> wrote:

[Jeff Lindsay]

No, but I've been planning various things around making auth easier/more flexible. For example, sometimes OAuth is desirable, but many APIs don't provide it. You could easily write a proxy that puts OAuth in front of an API that uses Basic Auth or something.

Related (although not necessarily relevant) I made something called keymaster that I use to keep my secret keys in the cloud, accessible to app I give access to. It works by having a shared key to trigger keymaster to POST the secret key to a predefined location. However, this is mostly to get around the fact App Engine doesn't provide user-definable environment parameters, which would also solve this problem to the extent I have.

[S Sriram]

Turns out that the ultimate POSS is google appengine 

here are 3 things in their 6-month roadmap  of interest

- Background servers capable of running for longer than 30s

- Support for Browser Push (Comet) communication

- Built-in support for OAuth & OpenID

from http://code.google.com/appengine/docs/roadmap.html