On the ROA

Instructors can now see their students as they assign grades, thanks to the IdCard Photo Service.  Now that Catalyst is consuming this service, we plan on taking advantage of it in many other Catalyst Tools in the near future.

UserVoice is our catch basin for Web service ideas, and if it ain’t there it’s probably not going to happen. At UserVoice you can share your Web service ideas, vote for ideas submitted by your UW colleagues, and join the discussion.

These ideas submitted to UserVoice have become a reality or are underway:

* Course description available in SWS

* Course url available in SWS

* Publicly available student Web services

* Person Web service

* Publicly available IdCard Web service

* Student transcript data

* Classroom scheduling Web service using R25 data

 Make your voice heard at: http://ontheroa.uservoice.com/

Version 1 of the Financial Web Service (FWS) is now in production. It provides access to UW budgets, vendors and organizations, including search capabilities, from a near-real-time data source. Several developers are already developing or modifying existing applications to use it. More information can be found in the documentation.

Since 2001, the Computer Science department has maintained its own collection of photos of CSE faculty, staff, and students.  We have a number of web apps such as photo directories or class lists that display these images.  We long ago settled on a standard size for the images and developed a procedure for adding a person’s name to the image.  But with Autumn quarter bringing in close to 200 new students, the process of capturing and processing these images is a lengthy one.

With the release of the IdCard web service this quarter, the work involved has dropped to near zero.  We can now automatically retrieve a student’s photo from the IdCard service rather than taking our own (note that by policy, we can only retrieve student photos, not those of staff or faculty).  Our undergrad program alone admitted 105 new students this quarter, and if we assume 10 minutes per photo, it would take over 17 staff-hours to collect all photos.  I was able to modify our existing infrastructure to take advantage of the IdCard service in one afternoon. This quarter alone, the time savings is huge.

The process was simplified because access to our local store of photos all went through a single PHP web app.  Students have the right to opt-out of having their photos displayed to the public or their peers, and one of the main jobs of this application was to control access to the photos depending on the person making the request.  My strategy is first to look in our local store of photos, and if one is not found then to try the IdCard service.  If found there, the photo is retrieved, normalized to our standards, and then stored locally.  The next time the photo is requested, it is found in local “cache” and no request to the web service is needed.

The design of the IdCard service makes this task quite easy.  The photo resource lets you retrieve the photo in the size that’s most convenient to you.  I request the photos in our standard dimensions and then use the PHP interface to the GD image processing functions to add a student’s name to the image.  That image is then stored locally along with all the others, and all of our existing infrastructure now takes full advantage of the IdCard’s photo resource.  If we wish to “override” one of the ID card photos, we simply take and upload a person’s photograph as before, and the new one is served preferentially.

One side-note is that, as with most web resources concerning students, the native identifier for a person is his regid.  We had never before used regids, keeping instead system_key and uwnetid for each user.  In order to collect regids, we use the person resource of the SWS to do a system_key to regid translation, and then save the regid locally so that this translation only happens once per person.

The listing of the IdCard service in the registry is awaiting some polishing of the documentation (restricted) but expected soon.  For access, contact Tony Chang or Paul Schurr.  To use this service, you will need to obtain a test and a development client certificate for your application which you will use to authenticate to the IdCard service.   Permission to use the resource is granted by the registrar, and before getting the final OK, you and they will do a short security review of your application.  It’s all easier than it sounds, and if you get stuck you can contact roa-technical@u.washington.edu and they’ll hook you up with someone who can answer your questions.

A couple folks here at the UW Seattle campus and I created a  SimpleRestClient class to help PHP devs programmatically consume RESTFul X.509 protected web services using PHP cURL. We feel that there is a small hurdle in developing against X.509 certificate protected web service resources so quickly created something to help PHP devs jump over that hurdle in addition to other challenges.

You can download the PhpRestClient and associated SampleApp from GitHub. BTW Github is the source control repository that we are using to host our UW Web Services Registry code.

http://github.com/tonychang/PhpRestClient (click on the download button)

You can simply untar the files into the same directory and run the sample app from any webserver with a current version of PHP on it.

Since this code was contributed by developers at multiple UW departments we consider this an UW Community Source project. Yea I just made up the term right now but think it has a nice ring to it. If you want to help contribute to the project just let me know and I can get you added as a GIT contributor.

This is just a first iteration of it and its possible that someone will add additional features like supporting all the HTTP methods (vs just GET and POST) and allowing for Basic/Digest HTTP authentication.  Stay tuned for something similar to help .NET devs.

The code is not officially supported but we are happy to answer any questions you may have.

Developers:

Dan Boren – Computer Science and Engineering

Tony Chang – Office of Information Management

Paul Hanisko – College of Education

The iPhone application uses Student Web Service V4 to power the course module. The app takes advantage of our new course search api, course description, and a new set of academic resources which are all publicly available. Here is the V4 documentation.

Read more on the Office of the University Registrar Blog and the UW Facebook page .

Another V4 feature we added SWS is the ability to submit a search query against course titles. You can now create your own application search feature for your users.

The below web request performs a course search using “info” as the contains search text against course titles. This returns 216 search results showing only 10 results at a time.

https://ws.admin.washington.edu/student/v4/public/course?year=&quarter=&curriculum_abbreviation=&course_number=&course_title_starts=&course_title_contains=info&sort_by=on&page_size=10

Lastly, we also offer paging so you can receive the total result count, page size, and page start to help you enable paging in your application.

Enjoy!

On August 3rd we released a new version of SWS.

This release still supports v3, and adds version 4 which introduces Campus, College, Department, and Curriculum search capabilities, as well as an update to Course search, and Section.

Click here for documentation.