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.
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!"
> 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<webhooks%2Bunsubscribe@googlegroups.c om>
> .
> 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.
On Wed, May 5, 2010 at 12:36 PM, Daniel Parker <dcpar...@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.
-- 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.
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.
> 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<webhooks%2Bunsubscribe@googlegroups.c om>
> .
> 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.
On Wed, May 5, 2010 at 1:41 PM, Jeff Lindsay <progr...@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
-- 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.
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??
On Wed, May 5, 2010 at 1:41 PM, Jeff Lindsay <progr...@gmail.com> 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 <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
>> do something with a web service
>> s/do something/allow users to add events
>> s/service/google calendar
>> 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<webhooks%2Bunsubscribe@googlegroups.c om>
>> .
>> 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<webhooks%2Bunsubscribe@googlegroups.c om>
> .
> 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.
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 <ssri...@gmail.com> 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 <progr...@gmail.com> 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 <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
>>> do something with a web service
>>> s/do something/allow users to add events
>>> s/service/google calendar
>>> 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<webhooks%2Bunsubscribe@googlegroups.c om>
>>> .
>>> 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<webhooks%2Bunsubscribe@googlegroups.c om>
>> .
>> 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<webhooks%2Bunsubscribe@googlegroups.c om>
> .
> 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.
On Wed, May 5, 2010 at 2:32 PM, Jeff Lindsay <progr...@gmail.com> wrote:
> 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 <ssri...@gmail.com> 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 <progr...@gmail.com> 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 <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
>>>> do something with a web service
>>>> s/do something/allow users to add events
>>>> s/service/google calendar
>>>> 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<webhooks%2Bunsubscribe@googlegroups.c om>
>>>> .
>>>> 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<webhooks%2Bunsubscribe@googlegroups.c om>
>>> .
>>> 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<webhooks%2Bunsubscribe@googlegroups.c om>
>> .
>> 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<webhooks%2Bunsubscribe@googlegroups.c om>
> .
> 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.
