These are the news items I've curated in my monitoring of the API space that have some relevance to the API definition conversation and I wanted to include in my research. I'm using all of these links to better understand how the space is testing their APIs, going beyond just monitoring and understand the details of each request and response.20 Mar 2015
I was listening to too infrequent Traffic and Weather API podcast today, and one of the topics John and Steve covered was an interesting approach to API consumption, and getting past API rate limits, with WebhookDB. I agree with John, that WebhookDB is pretty clever, and represents what I'd consider classic API developer ingenuity, when it comes to getting access to the resources they need. I’d have to give this one to my friend and API adversary Tyler Singletary (@harmophone), when he says rate limits stimulate developer creativity. +1 Tyler.
So, what does WebhookDB do?
...allows you to replicate Github's database over HTTP using webhooks. It's useful if you want to treat Github's APIs as a database, querying over pull requests and issues. Github doesn't like that, and you'll quickly hit the API's rate limits -- but if you use WebhookDB, you don't have to worry about it! Just populate the initial data into the database, set up the webhook replication to keep it in sync, and query your local database however you'd like...
There is more back-story over at the REST API gotcha, and webhookdb story that Traffic and Weather linked to. I agree with John’s thoughts, that this is an opportunity for a service provider to step up and deliver on. I envision a pretty simple, open source, containerized version, as well as a cloud-based version that people could tap into, and pay for more premium services on top of each index.
John is right, there will be significant overhead in defining the schema of each API you would support. Let me know, I can help with some of the targeting, alongside what I’m doing for my API Stack. Each API would need some special attention, but with containers, you could easily build out a pretty slick deployment solution that runs in cloud, or in infrastructure of choice for end-users. With some heavy lifting up front, it would be a pretty viable solution for API consumers, but I also think provide an interesting cache opportunity for API providers--think Datasift.
I also see a higher, more analyst level view here, in helping establish a common definition of web hook patterns across the space, and identify common patterns, then bring much needed education and potential consistency to the API space when it comes to webhook execution. Kind of like what I work to do for API design, deployment, management, integration, and other key areas of the API space. People are hungry for this type of information, and I’m happy to aggregate the work of anyone who steps up and delivers in this way.
I would also take this one step further, and charge someone with stepping up into more of a web hook advocacy role, where you could push back on some API providers to offer webhooks (many don’t), and improve existing web hook designs, again helping establish consistency in the space. In my experience many API providers want to understand the bigger picture, but don’t often have the time or awareness, and with a little education, and guidance, you could make a significant impact.
I look at webhooks as the important second lane, making APIs a two-way street, shifting API operations to be just as much push, as it is pull. Web hooks play a different role in potentially each APIs operations and ecosystems, but for many platforms, they will continue to play an important role in giving developers more control over API resources, while also eliminating much of the burden upon API providers.
Great idea John and Steve, thanks for sharing. One more reason to tune into Traffic and Weather—startup ideas!!
While I was at API Days this weekend in San Francisco, I managed to catch a handful of talks Saturday afternoon after I landed at OAK. While listening to each talk, I kept hearing one technical API building block, over and over--webhook.
Webhooks are a common way for API providers to make API integration a two ways street for consumer. Developers, or even non-developers, can setup webhooks via common API platforms, and receive notifications about different events and activities that occur.
Webhooks are also a common tool for API automation and reciprocity platforms like Zapier and IFTTT. Users can setup webhooks, that respond to just about any action across multiple, API driven platforms.
Webscripts are short scripts, written in Lua, that run in the cloud servers, and can respond to any HTTP requests.
Exactly what I was looking for. I had heard of webscript.io before, but for some reason it didn't stick in my mind. It is precisely the simple approach I was looking for, and has many common examples like sending emails, counters, parsing RSS and Tweeting.
- Application Billing - A built in billing and payment framework for Freshbook applications and beyond
- Webhooks - Framework for enabling application callbacks, URLs where the Freshbook system can send notifications to third party applications
- FreshBooks Add-on Store - Application store and development platform for developers to build custom apps, showcase, and sell to Freshbook customers.
If you think there is a link I should have listed here feel free to tweet it at me, or submit as a Github issue. Even though I do this full time, I'm still a one person show, and I miss quite a bit, and depend on my network to help me know what is going on.