The Utopian Library

Jason Clark, Digital Initiatives Librarian, Montana State University Libraries

Program description on the CIL2008 website.

Presentation handout at www.lib.montana.edu/~jason/talks.php¹

• Jason Clark is on the Web at jasonclark.info

On the agenda:

• Overview of web services protocols
• Acronyms and major terms associated with web services
• Benefits of web services for libraries
• Intro to the code that makes it happen

API (application programming interface)

• A way for developers to access parts of a remote website and integrate it with their own site.
  • can be queried, limited, and retrieve different forms of info
  • MSU example (RSS feed format) and site map format
    • query string to view API in sitemap format
      
    • query string to search API for Reference materials
      
    • query string to view in JavaScript Option Notation (JSON) format
      
  • Review the documentation and code to see what kind of info the APIs retrieve
  • Advanced API services are designed to allow developers to build apps on their websites that are as functional as the original site
    • example: YouTube API allows library to create its own YouTube page so that site visitors wouldn’t have to go to YouTube.com²
    • saves time

Web Service

• a remote call that provides access to data between systems
• returns structured data to the server that made the request

Structured Data

• Extensible Mark-up Language (XML) and JavaScript Object Notation (JSON)
• Flexible mark-up languages
• Lightweight and easy to parse
• Allows communication between disparate systems

POST and GET

• POST action: entering data and pushing it to a different site
  • Similar to an update function
  • Adds new data to a remote location
• GET action: reading data from another location and bringing it back to the site

Why use Web Services?

• Access to content/data stores that libraries could not otherwise provide (zip codes, news, pictures, reviews, etc.)
• Enhance library website with a service that is not feasible for the library to provide (maps, search, products, etc.)
• Combines multiple services into one seamless library service (mash-ups)
  • libraries can create a better product than they could without these resources

Why provide Web Services?

• A library service is of greater use to its users if they can get to the data from external applications
• The library wants others to use its data stores in their own applications
  • from the floor: is the authoring library identified anywhere in the code of the service it develops/shares?
    • header tags in the XML file are used identify library, copyright statement, etc.

Available Web Services

• Google
• Yahoo!
• Amazon
• eBay
• Flickr
• del.icio.us (see “Developers” section for RSS, API, JSON, HTML)
• Google App Engine
• Amazon s3
• …and many more!
  • AllCDCovers
  • ISBNdb.com
  • OpenDOAR
  • arXiv.org
  • see ProgrammableWeb

Types of Web Services

• Three basic protocols
  • SOAP (Google)
    • Simple Object Access Protocol
    • v1.2 of the W3C recommendation
    • essentially, XML files talk to each other
    • example: api.google.com/GoogleSearch.wsd
  • XML-RPC
    • XML Remote Procedure Call
    • an updating protocol
    • alerts to changes in content: think “ping”
    • used by Technorati, Flickr, FeedBurner, and others
    • early adoption, but little recent development
  • REST (Flickr, Google)
    • “the greatest thing since sliced… ”³
    • Representational State Transfer
    • unique data resources with addresses
    • the theory of REST
      • focuses on diversity of resources (nouns), not actions (verbs)
      • every resource is uniquely addressable
      • all resources share the same constrained interface for transfer of state (actios)
      • must be stateless, cacheable, and layered
    • REST is a Web protocol
    • similar to the Web
    • easy to understand
    • URL is the method
    • most popular type of service

Web Services in Libraries

• Plymouth State: Scriblio
  • WPOPAC: catalog built from blog software
  • uses Amazon or Google BookSearch API to retrieve cover images⁴
  • images are stored on local server to avoid throttle limits
• Repository66: mash-up of OpenDOAR data with Google Maps and repository growth charts from ROAR.
  • displays location and availability of research materials
• LibraryThing APIs
• LofiAPI: MSU Libraries (EDT, RMT)
• MSU Library Lifestream: RSS services (Twitter, del.icio.us, last.fm, MSU Library Blog)
• TERRApod YouTube admin
• Google Booksearch

Workshop Examples

• Google Ajax Search
  • puts Google Search on a website
  • can be used on any platform
  • search result looks like this; code looks like this
• Amazon Reviews & Thumbnails
  • displays like this; and this is the code
• Flickr API Display Photos
  • dynamic display
  • look here and here

Tips

• Play in the sandbox. Pick a service and study it.
  • Yahoo! Developer Network
  • Amazon Web Services Developer Connection
  • Google Code
• Consuming Web services
  • Pick a language or parsing tool
  • Find a few APIs worth learning about
  • Make some requests and look at the code in a Web browser
  • Think about added value and more efficient workflows
  • Look around– many language libraries are already written
• Building Web services
  • Use CRUD (Create, Read, Update, Delete) functions rather than HTTP (Get, Delete, Put, Post)
  • Keep verbs in API intuitive and memorable
  • Start small: simple, read-only requests
  • Roll it out in beta version– once it’s public, there are restrictions
• Building blocks of Web services
  • REQUEST: learn the protocol, ask for data
  • RESPONSE: receive the data
  • PARSE: pick the pieces you need
  • DISPLAY: format those pieces for display

1. what have I gotten myself into? [↩]
2. not that we’d want to do this, but that’s the idea of advanced APIs [↩]
3. J. Clark said that [↩]
4. Jason couldn’t recall which was being used at the time of this writing [↩]

Filed under: CIL2008, conference notes