Skip to content Skip to navigation

API Ecosystem

Proposed by: 
Zach Chandler and Sameer Marella
Number of Attendees: 
Where will the conversation continue?: 
api_developers in
Administrative Systems has launched a new enterprise-grade API Gateway for managing access and visibility to APIs at Stanford. We also plan to release an API Catalog to make it easier to discover all the various APIs and how to request access to them. A Community of Practice will anchor conversations around best practices and how to do this well. Also conversation about what to do about 3rd party SaaS APIs.

Presenters: Zach Chandler (DoR), Sameer Marella (AS)

Time: 10:15-11 AM

Notes: Aayush Neupane

Research Information Ecosystem = AS + DoR + SUL + SoM + ORA

  • Partnership among independent Stanford organizations
  • Need APIs to modularize services
  • Need to parter with AS to handle infrastructure
  • Could have bought own subscription for API/ESB but that is not a durable strategy, Central IT has to be involved

But it is bigger than research, API Ecosystem touches every IT application in the enterprise.

Every API at Stanford should be cataloged and visible to developers in "distributed IT". A given API might have restricted access, but at least all developers should know the API exists

In this case "API" ==  RESTful Web Services

Questions for the community

  • What system do you wish had an API?
  • What services do you wish the API had?

Support for system owners (aka business owners)

  • We want to help system owners become API owners, demystify that process and take away some of the work (Auth, etc.) while leaving business owners in control of policy and access

We need to build API sthat meet industry standards

  • Pragmatic REST
  • Need documentation schema (e.g. Swagger)
  • Need good developer experience (DX)
  • PBuild on what we learned from Apigee in 2012 (Rapid API Design Workshop)

Sameer Marella – UIT Administrative Systems

  • -       Worked to come up with a hosting central API system
  • -       Have hosted web services in the past
  • -       Vision - Developers can discover existing API by using the centralized infrastructure


-       Microservices

-       We are aware of antipatterns that could slow down the growth, actively trying to avoid those

-       Need to be thoughtful about growth

-       Be thoughtful about community practices in advance (

o   Api_developers -

o   What HTTP status codes people want? Keep the convo going

o   Community informed ecosystem in Stanford


How does centralized API work with existing SASS?

-       Stanford digital repository interested in research data

-       System ownership from existing SASS

-       licensing information

o   Figure out what can be used in campus

o   Data ownership

o   To be figured out by the community rather than one person making the decision

-       Have a process of evaluating level of data that 3rd party can access within Stanford

-       Point people to real documentation instead of Stanford having to recreate our own documentation

-       Example: ServiceNow

o   Allows access to its own API to create requests

o   Allows talking to another API to exchange data

o   How does a client manage the service?

§  UIT provides oAuth token, service now provides client ID, secret

§  If servicenow provides oAuth token, UIT will need a registry of that information

-       Stanford does have a lot of cloud services

o   If UIT doesn’t get involved, its easier for developer for work

-       Document and share the code/documentation


3rd Party API might not be properly configured. Some might be too powerful that calling the wrong endpoint might cause enough harm.



-       Ongoing developing and maintenance of APIs

-       What APIs are distributed ITs using/building?

-       25live API -> dashboard using its API

-       You can expose all your data, but understand what the underlying data contains

-       3 legged OAuth. The API will have all access scope, but the developer has to maintain what level of access a user gets

-       Research API during software discovery process. Use the CoP to advise Software Licensing on what consitutes a "good" API.

o   Check what scopes the API provides

§  Single scope to handle everything vs multiple with fine grained access level


Details on cataloging API

-       What to include on catalog

o   Not decided yet

o   Maybe all APIs used, internal or SASS

§  Internal APIs - Zach

o   Need to figure out the process - will engage the community in that process

o   API gateway

§  Live in production

§  Early 2018, transition

§  Campus map api already hosted

§  Financial information APIs (PTA lookup service, et. al.) already hosted

§  Workgroup API, and Student web services transitioning early 2018

o   API gateway not only about exposing data

§  Might this API be useful to someone else within Stanford?

·      Save time, save money, save data