Home > records, tools > IIW XIII: Evented APIs

IIW XIII: Evented APIs

October 18th, 2011

From Kynetx session on Evented APIs: overview: when something happens, this function alerts or does some action. Sam’s demo: new event consumer (account created), then form presented as event builder. Send (process) form as POST, JSON body or Get, then received event is displayed on a web page. Event consumer vs event generator.

So what? Phil’s accounts: TripIt, FourSquare, and Expensify: how to mash up those three kinds of data sets? Open TripIt books a trip and opens an expense report, checking in with foursquare adds expenses–helps to orchestrate these events and consequences.

Semantics? Context is an important part of the picture. Event generators are going to be responsible for semantics, need consistency. Longer-term problem is, as a developer, need to map and look-up language to find mapping.

How does someone build an app around this? Anything that can receive a GET or POST can use this. Look at “If this then that” for wizard-like way of implementing. There may be reasons to encrypt return traffic or apply higher level security, can be added on top as function.

Possibly related posts:

  1. IIW XIII: VRM, Evented APIs, and Everything
  2. IIW XIII: The Final Overview
  3. IIW XIII: Connect.me and the social vouch-a-thon
  4. IIW XIII: Yubico
  5. IIW XIII: Hypothes.is

records, tools

Switch to our mobile site