Fast integrations for Fun and Profit

Editor's Notes

• #2: Marsh on Product team. I started working on Apigee 6 years ago this week! Carlos on the SE team. We’re the kind of folks who tend to cause trouble (usually the good kind!)
• #3: If you’re here today, we’re going to assume that you already love APIs. Over the next 40 minutes, we’re going to talk a lot about webhooks, … and our goal is that if you don’t already, you’ll love webooks by the end of this talk.
• #4: Everyone here understands the power of APIs. Once you get API religion, you can't stop thinking about how your business should work as a REST API. But too often we think about these APIs from the Pull perspective. While a Pull API is table stakes, sometimes it's the wrong way to think about things (everything looks like a nail). Sometimes a PORA (Plain Old REST API) is not enough. With such a wide range of tools in the world today, it is impossible to accommodate all the ways in which people need data to move. You cannot predict every possible connection. Every new tool adds to the problem. People expect to access data in more places every day. “We have REST APIs!” the tools shout. But is it enough? What makes two APIs talk to each other? (sotto voce: glue code) The workload isn’t going down… in fact it’s going up. We're in the middle of connecting SoR to SoE. SoE is built on engagement. We know that integrations are sticky. Make your service more useful with push! If you expect your customers to come to you, you're dead. You need to be where they are or they will go to someone else. By enabling developers to hook into events, you enable a special kind of integration, an especially sticky one that makes your product more useful with another, which increases retention and drives revenue.
• #5: How many of you have a REST API today? (keep your hands up…) How many of your APIs have Webhooks live in production today? How many of you have written an of integration that leveraged a Webhook? … was it Slack? (note the joke that we’re polling about webhooks!!!)
• #7: Jeff Lindsay coined the term around 2007. He asked, “What is the equivalent of the pipe in the age of the web?” “The Unix pipe is simple because it's about linear input and output of text streams. The web is very different […] web hooks achieve the same simplicity but more appropriately for the web.” They’ve been around for EIGHT YEARS and we’re still struggling with how to really use them. (yrs is still better than REST) Also, very important, no capitals unless it starts a sentence or is title cased!
• #8: https://groups.google.com/forum/#!topic/webhooks/4Wck6B8hsLw Effectively async Basically synchronous, though could be nested in an async client This is like webhook tennis: the original event triggers some logic that calls back into the system, effectively async
• #9: This is really a notification use-case. Because there is no response, it’s really an event-based asynchronous notification. We’ll touch on this later with Slack, in which this is an outbound webhook, based on trigger word matches. It doesn’t expect anything back.
• #10: This is very much like a regular API in that there is a call and response that the
• #11: https://www.twilio.com/platform/webhooks Start recording the call. This is very much like #2, only non-blocking. This is “Webhook Tennis!”
• #12: https://creativecommons.org/licenses/by/2.0/ from Kyle May: https://www.flickr.com/photos/kylemay/2085998790
• #13: Cron jobs, cron orphans Parsing, Caching… Also, you can buy this sign here: http://www.safetysign.com/products/p7645/dont-call-us-well-call-you-sign
• #14: If the events are a constant stream, and HTTP overhead is too much, or it would be better to just be bidirectional Queuing can be an intermediate step, essentially batching events to make the system more efficient. Moving log events is a good example. This is still polling though… PubSub: good if you’d rather have an external system deal with
• #17: It’s gotta get there somehow… Useful for idempotence, but it’s up to the receiver to do anything with it For verifying the source of the request, but it’s up to the receiver to do anything with it. Information about the event itselfNothing after #1 is required, required, even this What the receiver sends back to the server
• #19: Really nice documentation. Gives a POST form-data example, very common. Decent info on the response as well.
• #20: There may not be any server-side state change from the webhook. In that case, why not let developers decide what’s right for them? Why Slack integrations are awesome: Available to all users by default No application or registration required Everyone can see what integrations are enabled Built in token mechanism including regeneration /slash as well as triggers
• #22: A GitHub Post-receive hook is very much like #1 without the rest of this.
• #24: Apologies, it’s hard to read because there are A LOT of options—they don’t even fit on this page. It’s probably time for a refactoring! Note: this is a good example of a #1 pattern Slack or HipChat integration. Jira just alerts about new issues and expects no response.
• #25: This enables devs to deal with security at their own pace. Note, you cannot enforce what devs do here. Consider sample applications.
• #27: https://www.bugherd.com/api_v2#api_webhook_list BugHerd, GitHub, and Trello all work this way https://developer.github.com/v3/orgs/hooks/
• #28: See: https://developer.github.com/v3/oauth/#scopes
• #31: https://developer.paypal.com/developer/webhooksSimulator/
• #33: FOLLOW ALONG HERE: https://github.com/iloveapis2015/swagger-node-slack