Received: by 10.115.66.9 with SMTP id t9mr2974242wak.19.1273095129254; Wed, 05 May 2010 14:32:09 -0700 (PDT) X-BeenThere: webhooks@googlegroups.com Received: by 10.115.38.17 with SMTP id q17ls6617031waj.0.p; Wed, 05 May 2010 14:32:08 -0700 (PDT) Received: by 10.142.2.42 with SMTP id 42mr2670788wfb.4.1273095128523; Wed, 05 May 2010 14:32:08 -0700 (PDT) Received: by 10.142.2.42 with SMTP id 42mr2670787wfb.4.1273095128446; Wed, 05 May 2010 14:32:08 -0700 (PDT) Return-Path: Received: from mail-pv0-f194.google.com (mail-pv0-f194.google.com [74.125.83.194]) by gmr-mx.google.com with ESMTP id 18si49126pzk.10.2010.05.05.14.32.07; Wed, 05 May 2010 14:32:07 -0700 (PDT) Received-SPF: pass (google.com: domain of progr...@gmail.com designates 74.125.83.194 as permitted sender) client-ip=74.125.83.194; Received: by pvg4 with SMTP id 4so31854pvg.9 for ; Wed, 05 May 2010 14:32:07 -0700 (PDT) MIME-Version: 1.0 Received: by 10.142.195.20 with SMTP id s20mr1920056wff.248.1273095126606; Wed, 05 May 2010 14:32:06 -0700 (PDT) Received: by 10.142.192.20 with HTTP; Wed, 5 May 2010 14:32:06 -0700 (PDT) In-Reply-To: References: Date: Wed, 5 May 2010 14:32:06 -0700 Message-ID: Subject: Re: [Web Hooks] moving apis up a (webhook) notch with a POSS service From: Jeff Lindsay To: webhooks@googlegroups.com X-Original-Authentication-Results: gmr-mx.google.com; spf=pass (google.com: domain of progr...@gmail.com designates 74.125.83.194 as permitted sender) smtp.mail=progr...@gmail.com; dkim=pass (test mode) header...@gmail.com X-Original-Sender: progr...@gmail.com Reply-To: webhooks@googlegroups.com Precedence: list Mailing-list: list webhooks@googlegroups.com; contact webhooks+owners@googlegroups.com List-ID: List-Post: , List-Help: , List-Archive: Sender: webhooks@googlegroups.com List-Subscribe: , List-Unsubscribe: , Content-Type: multipart/alternative; boundary=000e0cd32bf2c9636c0485df8ef2 --000e0cd32bf2c9636c0485df8ef2 Content-Type: text/plain; charset=ISO-8859-1 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. On Wed, May 5, 2010 at 2:17 PM, S Sriram wrote: > 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 wrote: > >> 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. >> >> On Wed, May 5, 2010 at 11:38 AM, S Sriram wrote: >> >>> 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 webhooks@googlegroups.com. >>> To unsubscribe from this group, send email to >>> webhooks+unsubscribe@googlegroups.com >>> . >>> For more options, visit this group at >>> http://groups.google.com/group/webhooks?hl=en. >>> >> >> >> >> -- >> Jeff Lindsay >> http://progrium.com >> >> -- >> You received this message because you are subscribed to the Google Groups >> "WebHooks" group. >> To post to this group, send email to webhooks@googlegroups.com. >> To unsubscribe from this group, send email to >> webhooks+unsubscribe@googlegroups.com >> . >> For more options, visit this group at >> http://groups.google.com/group/webhooks?hl=en. >> > > -- > You received this message because you are subscribed to the Google Groups > "WebHooks" group. > To post to this group, send email to webhooks@googlegroups.com. > To unsubscribe from this group, send email to > webhooks+unsubscribe@googlegroups.com > . > For more options, visit this group at > http://groups.google.com/group/webhooks?hl=en. > -- Jeff Lindsay http://progrium.com -- You received this message because you are subscribed to the Google Groups "WebHooks" group. To post to this group, send email to webhooks@googlegroups.com. To unsubscribe from this group, send email to webhooks+unsubscribe@googlegroups.com. For more options, visit this group at http://groups.google.com/group/webhooks?hl=en. --000e0cd32bf2c9636c0485df8ef2 Content-Type: text/html; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable No, but I've been planning various things around making auth easier/mor= e flexible. For example, sometimes OAuth is desirable, but many APIs don= 9;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, accessibl= e to app I give access to. It works by having a shared key to trigger keyma= ster to POST the secret key to a predefined location. However, this is most= ly to get around the fact App Engine doesn't provide user-definable env= ironment parameters, which would also solve this problem to the extent I ha= ve.

On Wed, May 5, 2010 at 2:17 PM, S Sriram <ssri...@gmail.com> wrote:
Hi,

The current direction seems to be more the 'so easy yo= ur browser can do it'=A0
javascript apis way ala @anywhere=A0= / fb open graph etc.=A0
as opposed to the ApiApps way (twimlets n= otwithstanding)

I agree that defer-ing things makes things easier. My o= utline 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=A0

i.e. a multi-se= rvice 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 <progr...@gmail.com> wrot= e:
I think we're moving in this direction, slowly but surely. I've act= ually built one-off types of scenarios like the one you've described. I= 've envisioned a sort of ApiApps service for similar and different reas= ons. It'll happen eventually, but I don't see a huge reason to forc= e it just yet. The longer you can defer these kinds of things, the easier t= hey'll be.

On Wed, May 5, 2010 at = 11:38 AM, S Sriram <ssri...@gmail.com> wrote:
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=A0
= =A0=A0 =A0do something with a web service

=A0=A0 = =A0s/do something/allow users to add events
=A0=A0 =A0s/service/google calendar

=A0=A0 = =A0s/do something/status update
=A0=A0 =A0s/service/twitter
=

Current scenario
-----------------
= 1. get api keys,
2. Wade through docs at developer.foo.com,=A0
3. grab oauth code libs,
=
4. write code,
5. test

The Problem<= /div>
-----------
Steps 2-5 take time, effort and a reasonably high degree of skill and = are replicated
over and over by each developer on their implement= ation.

The Solution
------------
ApiApps using webhooks on a POSS server

ApiAp= ps are sinppets of hosted code that encapsulate the access to
var= ious web apis(producers) and are made available to api consumers
via simple http calls.

As an example lets take goo= gle calendar.

If acme.com (api consumer) wants the ability to have its even= t be added into
its customer John's (user) google (api producer) calendar. It need= s to
1. Get an oauth token from John
2. Create an api c= all 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 'cann= ed' microsite that=A0
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 cale= ndar
d) Instituted rate-limiting measures etc. and provided for an
=A0=A0 upgrade path out of POSS to Paid/hosting etc.

=
Life for acme.com wo= uld be much simpler, foo.com would see a much
greater adoption of its api/services and peace will reign on
earth :-)

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=A0
4. User John clicks on this link
5. apiapps receives this re= quest and does a signed api http POST call to
=A0=A0 http://www.acme.com/api= apps/start with unique-key as a param.
6. acme.com/apia= pps returns a JSON set of params for the google calendar
=A0= =A0 call i.e. date, event description etc.
7. apiapps - saves thi= s =A0info=A0
8. apiapps than gets google oauth credentials from John (saves that fo= r
=A0=A0 future reference)
9. On getting John's credential= s, apiapps on behalf of acme makes the
=A0=A0 google calendar api= call/entry
10. apiapps than sends a confirmation to acme.com/apiapps/finish

So, for acme.com to offer google calendar apiservi= ces to its users
required
1. A onetime setup with apiapps
2. Addition of an apiapps li= nk to website where needed
3. Writing 2 url handlers=A0
=A0=A0 - acme.= com/apiapps/start
=A0=A0 =A0 =A0 which gets called by apiapps and returns a json payload=
=A0=A0 =A0 =A0 detailing what needs to be done.
=A0=A0 =A0 =A0 which gets called by apiapps with a POST containing con= firmation
=A0=A0 =A0 =A0 detils, api call output etc.
This is 'rel= atively 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 s= ervice.

Long term sustainable funding for the POSS= service should be possible=A0
from api producers interested in seeing more rapid adoption of their
web services and with the raft of new cloud hosting services a mig= ration
path to paid for high volume users should be possible.

--x--

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



--
Jeff Lindsay
http://progrium.com

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

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



--
Jeff Lindsa= y
http://progrium.com

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