University as Platform – Jim Phelps, U Wisconsin Madison
In conversation with Undergraduate Advising, found that they have to use an average of 7 tools for every task they want to accomplish when talking with a student. They spend 40% of time navigating systems to perform a task, 40% teaching students how to use the systems, and 20% of their time doing high value advising.
Platform principles: resusable, transparent, leveraged, consistent, fiscally efficient, drives agility and innovation.
Second use case – the curricular hub. Spent a lot of up front time building it, but then requires very little reinvestment afterwards. Now have 27 different consumers, all getting the same answers.
Web Services, Authorization and the API Economy – Scotty Logan, Stanford
Data extracted from programmableweb.com – which doesn’t have an API.
About 9k APIs registered – straightline log chart since 2005. Mostly REST, SOAP coming back a bit. API Billionaires Club: twitter, google, facebook, netflix, etc.
90% of Expedia’s business is through APIs, half of Salesforce’s access is through the APIs. 1.1 million requests/second on S3.
Drivers: Mobile, cloud, social, desire to be open, competitor has an API
We have a dysfunctional relationship with the cloud – we’re consumers of APIs, and sometimes we produce APIs, but not consistently or on a huge scale. Who allows the cloud to push and pull data? Who allows mobile apps to push and pull? The mobiel app economy relies on the API economy. How well do your apps work without a network? The Internet of Things relies on the API economy.
API Value Chain – App user->App Store->App->App developer-> world of APIs-> API-> API Team-> Internal systems. App developers are kingmakers – so they’re the ones you have to get APIs to.
Web Services – SOA is dead – long live services (Anne Thomas Manes, Gartner).
SOAP or REST? REST is more popular now, means more tools and libraries, examples, design/dev experience. SOAP uses HTTP, REST is HTTP.
Authorization – how does a person allow one appt to access their data in a different app? Shibboleth (SAML) is great if there’s a browser involved. How do you authenticate if there’s no app? OAuth + REST – Designed for REST-like APIs. Like REST, OAuth leverages HTTP features and response codes.
Allows a client application to ask a user for restricted permissions to act on their behalf / access their data in another system without exposing credentials.
OAuth authenticates apps, not people. OpenID Connect authenticates people and is built on top of OAuth 2.
OAuth 2.0 vs 1.0/1.0a
OAuth 1 required signatures – harder than it looked. OAuth 2.0 relies on SSL/TLS – additional RFCs for signatures, JOSE specs for signed/encrypted tokens.
API Evangelism and support at Stanford – Goal is make it easier to create and deploy APIs and to find and user APIs “the right way”.
In the beginning – helped a few groups create basic APIs. Scott & Bruce as API evangelists – please make APIs, please make them RESTful, please use OAuth.
Med School CAP System – Community Academic Profiles – expanding to all faculty and staff. Other apps want data from CAP – “we’d like help with an API!” – two day REST design session with vendor. Investigated their API management tool – concerns about integration, cost. They wanted SAML – AS, token attribute passing, scope approved, rate limiting, API console, distributed ownership/control, workgroup integration (groups).
Found a few open source API management tools – big bloated unfamiliar framework or obscure implementation language or no OAuth 2.0 support.
They’re rolling their own – three pieces: OAuth Authoriztion Server; API Proxy/Gateway;
Using CloudFoundry’s UAA, CLient Credentials flow available now.
Developer portal – probably Drupal, wil integrate with OAuth AS.
Federated OAuth is possible.
Web Services Gone Wild! Mojgan Amini, UCSD
Users were happy with their green screens – then came web applications, first with Perl then with Java. Had users using web apps and others using green screens. They centralized common services, giving birth to their middleware. Every new technology got wrapped into the middleware, which got very bloated. Attended 2006 Gartner Web Services Summit – SOA is the wave of the future. Churned out 2000+ web services! Lesson learned: a little more effort on governance up front would be a good thing. Then created a good set of web services that were reusable that were heavily used – starting with commonly used public services. Then started talking with admin users who wanted real time data over web services – provided a select set of authorized services for their purposes. Put them in a good place for launching mobile apps when they were needed.
Still have Cobol, Perl, and Java apps along with 2000 base web services. Moving to a Red Hat middleware solution. Hoping to address self-service campus web services.
Student Developers, Web Service APIs, and OAuth – Mark McCahill, Duke
Two cautionary tales about what can happen with student developers, web APIs and how OAuth can maybe help.
Duke launched Innovation CoLab – effectively a long format “hackathon” – student dev teams compete to identify and address campus needs, in hopes that useful apps will emerge along with more insight how to support the institution. Has pushed a bunch of changes within OIT because students want to move fast.
Planning for CoLab – how can we enable student dev innovaation – infrastructure (easy): on-demand VMs with pre-installed application stacks for student servers (60 different images using BitNomi); self-service Git repository + bug tracking. Enterprise data in easy-to-use form for mobile apps and alternate user interfaces (harder). What data to they want? In which formats? SOAP+WDLs? XML-RPC? REST + JSON? The last won – students didn’t touch the others.
Impedance mismatch between what students want and what IT staff are used to doing. Enterprise developers are used to servers and app stacks hand crafted by artisan system administrators. Enterprise devs use Java frameworks etc. Student developers want on-demand PPAS services such as Heroku and software ecosystems such as Node.js, Ruby-on-Rails, JSON, REST, curl, screen scraping.
CoLab; Note Cheese – Sharing class notes is a good thing; you don’t know everyone in your class and you don’t know who took good notes. Might end up with something liek Quora meets Piazza with class notes. Why make users type in their class schedule? Devs can’t get class schedules via API, so they asked for NetID and PW, then screen scraped the classes.
Lesson: OAuth opt-in and informed consent to access individual class enrollment? Allow students at least some access to Shibb SP signup tool – policy now is that students can’t get SPs, so need to change that. Provide pre-built shib along with API stacks.
CoLab: Hack Duke – Enterprise via REST – read-only REST access to everything. Live drill-down navigation of the APIs: classes, terms, course evaluations, departments. Event calendar, map coordinates, LDAP directory via REST. Available on GitHub. Backend is MongoDB, nodeJS front end. a fork of openworld. Some concerns are expressed – controlled access to sensitive data? All students can view course evaluations, but should the public see this? Frequency of updates? Data validity? departments offering courses <> all departments.
Lessons: if you don’t provide enterprise data in easy-to-use forms, the students will do it anyway. read-only REST + JSON is the way to roll. Realtime browsable catalog of APIs (requiring an API key). OAuth for non-toxic user opt-in for release of data to applications, Expectation of live data for realtime course registration decision making.
Oren Sreebny 