!SLIDE #Building an SEP API ##Matt Swanson ##November 29, 2011

!SLIDE bullets

Why - Mission

• We have some neat data
• It’s hiding in plain sight
• Let’s do something cool with it

!SLIDE bullets

Why - Internal projects

• Shared code - auth, employee DB
• Decoupled, easier to maintain
• Smaller scope
• Multiple interfaces to same data

!SLIDE bullets

Why - Metrics/Analysis

• Case study: morale tracker

!SLIDE bullets

Want to know the company mood right now?

• Make a call to morale.sep.com/api

!SLIDE bullets

Why - Target Practice

• Want to play around with making an iPhone app?
• Hook into some SEP API - the data is already there

!SLIDE bullets

Why - Target Practice

• Want to try to make a command-line version of TET?
• Go for it - APIs give flexibility on the clientside

!SLIDE bullets

Why - Target Practice

• Want to make an Arduino blink a red light when the build breaks?
• Just ping an API and turn on power to that LED

!SLIDE bullets

Why - Fun

• Make an app that tells me who’s birthday is this week
• I hit a button and it tweets them “Happy Birthday”

!SLIDE bullets

Why - Fun

• “You really rock!” app
• I pick an employee and hit a button
• They get sent a You Rock card
• Amazon ships their favorite candy to the office

!SLIDE

Dasher demo

!SLIDE bullets

What kind of APIs do you want?

• Employee birthdays
• Employee favorite candy
• Brownbags
• Project team members
• Out of office switch

!SLIDE bullets

• Merit badges
• Build/CI status
• Employee internet presence
• You Rock cards
• Printers
• Timetracking
• SEP Library

!SLIDE bullets

How?

• If you are interested, let me know
• HTTP/REST is universal
• Use ASP.NET/Rails/Perl/Node
• Decoupled, with a maintainer

!SLIDE

What are YOUR thoughts?