1. Ashish Pandit, Louis Zelus, Jonathan Whitman
Free the Data (API)
Ashish Pandit, Louis Zelus, Jonathan Whitman
Introduction
Why API?
Managed APIs
API Manager Demo
Getting involved

2. Agenda API Managed API API Manager Demo
Campus initiatives with regards to API

3. Free the Data (Responsibly)
Data is captured by individual departments
Student admission office
§  Admissions
Academic system generates
§  Student Academic Data (waitlists, class registration, student academic status, grades etc.)
HR is storing
§ HR Person
§ Student contact information
Financial system stores
§ Student financials, holds

4. Companies don’t just provide one applications
How do we create multi-channel experience?

6. What is an API?
An API is a Business capability delivered over the internet to internet or to external consumers
How is it different from web service.
In theory, theory and practice are the same. In practice, they are not
Available using standard web protocol
With well defined interface
Designed for accessed by third parties

8. API Growth

11. Introduction to REST The six characteristics of REST:
Uniform interface
Stateless
Cacheable
Layered
Decoupled client-server interaction
Extensible through code on demand (optional)
* Services that do not conform to the above required contstraints are not strictly RESTful web services.
Paraphrased from Wikipedia:
The REST architectural style describes six constraints applied to the architecture:
Uniform interface
This is the API of the web service, describing operations and data structures.
It simplifies and decouples the architecture of both client and server, enabling each to evolve independently.
Client–server decoupling
Clients are separated from servers by a uniform interface.
For portability, clients must not concern themselves with data storage.
For simplicity and scalability, servers must not concern themselves with the UI or user state.
Servers and clients may be replaced and developed independently, as long as the interface is not altered.
Stateless
No client context should be store on the server between requests.
Each request contains all of the information necessary to service the request and session state is held in the client.
The server can be stateful, but server-side state must be addressable by URL as a resource.
This makes servers:
More scalable.
More visible for monitoring.
More reliable in the event of partial network failures
Cacheable
Clients may cache responses, so responses must define whether they are cachable to prevent clients reusing stale or inappropriate data in response to further requests.
Well-managed caching can eliminate repetitive client–server interactions, further improving scalability and performance.
Layered system
A client’s connection to a server may pass directly to the service or through several intermediaries, allowing:
Scalability by enabling load balancing and by providing shared caches
The enforcement of security policies.
Code on demand (optional)
Servers may temporarily extend or customize the functionality of a client by transferring logic to be executed. (e.g. client-side JavaScript)
If a service violates any constraint other than “code on demand”, it cannot strictly be referred to as REST web service. Complying with these constraints, and thus conforming to the REST architectural style, will improvie a service’s
Performance
Scalability
Simplicity
Modifiability
Visibility
Portability
Reliability

13. Roles Roles Functionality API Developer Browse the store, Create APIs
API Governance Committee
Approve and Publish API
Application Developer
Browse the store, Subscribe to APIs
Application User
Needs to be authenticated and authorized
IT Owner
View Reports,
Monitor Performance
Data Owner
Provide Subscription Approvals,
View Reports

15. Demonstrate – Student Eligibility API
1. API Developer creates an API
2. Publish the API
3. Application developer subscribes to API
4. Approves access to API
5. Application Developer Subscribe application to API, get Key and Invoke API
HTTP Method
URL Pattern
Payload
GET
students/{id}/eligibility/academic?
termCode={termCode}&academicLevel={academicLevel}
Response
reasonList – string
Status – string (S, F, W, E)

17. How do I publish my APIs to the store?
API Manager Infrastructure Q3
Governance Committee
Define the process
Define the interface

18. Campus API and Governance
§   Admissions
§  Transfer coursework
§  Current and permanent address
§  General admission data (major, etc)
§   Registrar
§  Coursework
§  Registration status (by term)
§   Person
§  Data codes
§  Current and permanent Address
§  Address
§ Data Warehouse dataAccess Link API (ability to integrate apps easily into access link)"
§  View/Lift/Place holds
§  View majors
§  View  minors
§  View Cum. Gpa
§  View Student Academic Data (class list, waitlists, academic status registration status, etc.)
§ Student contact information
§ Preauthorization

19. SOA Governance

20. API – Use Case Preauthorizations for Courses Current process
By hand
By hummingbird script
Colleges – First Year Experience Course
3,300 Pre-authorizations to place
Use of API server to place Pre-authorization in batch
Phase 2 – campus effort
Thousands of preauthorizations placed by campus staff for students into courses.
Partners include EVC and CSE

21. Publishing UCSD
Agility

22. Getting Involved
SOA Governance committee
SOA Center of Excellence (COE) – (In progress)
Contact:
Ashish Pandit
Jude Poole

23. Questions?