REST, JSON, XML, SOAP, includes, expands, WSDL, ContentNegotiation, Accept Headers. Yep, thats the normal lingo these days. All of this has quickly replaced database connections to remote systems. All part of a Service Oriented Architecture. Instead of someone central being responsible for each application that talks to a central datasource, and building custom solutions for each, just build an API, give developers the keys, and let them build their own integrations. Its working.

As of Today, here’s the API’s we are using:

  • PersonBioDemoService – SOAP – XML – Access people from PeopleSoft. You get their affiliations with the university, appointments, academic status (major, fees paid), phone numbers, and addresses. Authenticating with SOAP is a bit of a bear, so we’ve only been able to get this working in Grails+CXF plugin. We lost a week or two trying to get Rails to authenticate, and never got it working. Also, sticking with Java meant that it automatically parsed the wsdl, and generated all the code for interacting with all the endpoints and data elements. I love WSDL, and automatically generated clients. One endpoint supports bulk requests, we’re typically paging at about 250 people per request. Near-real-time. Talk to Glenn to find out if this is right for you.
  • PersonDelta – REST – XML/JSON – Get a list of emplid’s that the person has had some type of HR change. You can ask for people who have changed in the past day, week, or month. For systems that need to be synchronized, we have them polling from this each day, week, and month to get a list of people that we need to reprocess. Talk to Glenn to find out if this is right for you.
  • CotaService – SOAP – XML – Get a person’s Track1 from their BuckID, given their emplid. We want our circulation desk to be able to lookup a person who comes to the desk with a simple card swipe, the magnetic track 1 of BuckID’s is not considered sensitive information, so we populate our system with everyone’s Track1 for lookup. We’ve worked with Student Life to get this built.
  • FindPeople – REST – XML/JSON – Get public information from the people directory. Gets their address and office properly formatted according to how everyone understands these to be. This is near-real-time. This is public
  • — Find People XML: http://directory.osu.edu/fpxml.php?name_n=dietz.72
  • – – Find People JSON: http://directory.osu.edu/fpjson.php?name_n=dietz.72
  • KmData – REST – XML/JSON/HTML – Get an enormous of data about various university entities. We’re mostly using Departments, Groups, and People. Departments, given a specific org-code such as 32015 (Library IT), it will list all the people that work in that department. We then pair that with People, so that we can look up additional information about a person, such as getting all of their appointments, phone numbers, office addresses. You can also get Research in View information, to find out people’s publications. KmData Groups is interesting, since its a web UI that you can maintain groups of people. We’re using that to put people into various workgroups, committees, and other ad-hoc groups. We also have a group for people who have dotted-line reporting to the Libraries. i.e. They don’t work for the Library, but their office is in the Library, and they are always side-by-side with Library people, that for the purposes of a staff directory, we’ll count them as Library. There’s plenty of other Kmdata Endpoints, things that will be VERY interesting in the future includes buildings, as we’ll be bringing online access to the architect building database, which includes dimensions, floorplans, and other magic. This is up-to-date according to some ETL schedule. This is public, and is “open source”, so you can contribute to improve this service. For people: https://kmdata.osu.edu/api/people/api?id=278236
  • OPIC – REST – PNG – Given an OSU name.#, you’ll get their photo, useful for having a person’s avatar next to their posts, or for having a bunch of smiling mugs, for a staff directory. Ex:  https://opic.osu.edu/dietz.72

API’s that we have created:

API’s that we have in the pipeline:

  • Study Room In-Use – We have a project to put motion-detectors in group study rooms, that should tell us if someone is using a study room or not. We’ll then add this to a floor map to see where you can find an empty study room. We have lots of buildings, lots of floors, and lots of rooms, and sometimes there will be an empty room _somewhere_, maybe except during finals when the house is PACKED!!
  • Library Staff Directory – We’re not sure if our in-progress staff directory app will have an API, but it could, and that would make it very cool, to be able to embed lists of people in your department.
  • JobsAtOSU – We’ve toyed with the idea of scraping data from the University’s JobsAtOSU site, so that we can make a feed of jobs available within University Libraries, and then put that up as a widget within our Jobs@Libraries page. Either “here’s three openings within Libraries”, or “no job vacancies within Libraries”.
  • ReportsTo – Our rails app needs a way to find out who someone reports to in their job, to help us build a richer staff directory. Since we can’t solve the problem of getting rails to speak to the data provider, we might build a proxy layer in grails, that handles the dirty work of speaking SOAP, and provide the Rails app a cleaner endpoint to talk to.

I hope this was helpful. If you know of other Web Services available on campus, let me know.