Re: [CODE4LIB] Integrating with your ILS through Web services and APIs

[Robert Fox]

> I heard someplace recently that APIs are the newest form of vendor 
> lock-in.  What's your take?

If you use a design pattern like MVC on top of the API (assuming you're 
building a web app on top of the API), then it doesn't have to be a lock-in 
scenario. It is amazing, though, how much proprietary stuff vendors sneak into 
so-called standards based web services. No matter what you're doing with the 
API, you'd probably want to build some sort of abstraction layer on top of it 
so that it would be easier to swap out if you changed vendors or ditched the 
vendor all together. That's assuming you could extract your data from the 
vendor product... ;-)

Rob Fox
Hesburgh Libraries
University of Notre Dame

Re: [CODE4LIB] Integrating with your ILS through Web services and APIs

[John Fereira]

Robert Fox wrote:
I heard someplace recently that APIs are the newest form of vendor 
lock-in.  What's your take?


If you use a design pattern like MVC on top of the API (assuming you're 
building a web app on top of the API),


 then it doesn't have to be a lock-in scenario.

That's exactly what I have done to create a suite of library services 
that are currently being integrated into a new web site.  It should be 
noted, however, that using a MVC pattern doesn't mean that content 
brought in via a API in a data access layer can only be consumed using a 
web browser.  For my services, I've created multiple implementations of 
the View layer.  For example, a staff directory, which I obtain using an 
API I wrote which accesses an external staff directory app brings the 
data into a model which can be viewed as html, xml, json, and even will 
produce a dynamically generated PDF that staff can print off and place 
on their cubicle wall.  Other services have data related information 
(workshops, events, etc) have a view which produces iCal.