Django, Heroku, and the 360Link API
09-11-12
This post describes a demo application that serves as a front-end to the 360Link OpenURL resolver
from Serials Solutions. The code is available on Github and the application is running on Heroku.
A recent thread on the Code4Lib mailing list discussed technical details of the 360Link OpenURL resolver. The technical details are interesting because the OpenURL resolver is often the last handoff from the library systems to the location on the web where users can actually get what they are looking for. If something goes wrong, it's a frustating experience for everyone involved.
Over the last year, my colleagues and I at Brown University Library have developed a new front-end to 360Link using the 360Link API. It's been serving OpenURL requests since February and, as of August, has completely replaced our use of the default 360Link interface. The main objective of this project was to streamline the delivery of content found in various databases.
Since 360Link is rather popular in academic libraries and other libaries might be interested in implementing their own front-end, I decided to put together a demo Django application that uses the API to create a basic link resolver.
Here are a few sample links. You can also paste an OpenURL into the form on the index page
- Sample article lookup
- Pubmed lookup
- JSON(P) responses via content negotiation or adding output=json to the OpenURL.
- Another sample response but a customer code has been added to the url to switch to another library's API.
You can easily switch libraries by adding another library's Serials Solutions customer code to the URL - e.g Brown's default 360Link interface is at http://rl3tp7zf5x.search.serialssolutions.com/ so the customer code is "rl3tp7z5x". While testing this, I noticed that some library's API requires authentictation but most seem to be open and testable.
To run some real requests through this app, you could login to Mendeley and set it as your resolver in the “Find this paper at” dropdown menu.
The app is running on Heroku and the code is on Github. As far as I know, any library that subscribes to 360Link also has access to the API, so you could checkout this code, make a few tweaks, and have it running for your library pretty quickly. If you take a look, you'll notice that it's a couple of URL routes and a few dozen lines of controller (view in Django) code. So it takes less work to get started with the API than you might suspect.
For more details about working with the API, Daniel Talsky did a nice job of explaining the API in Issue 4, 2008 of the Code4Lib Journal.
At Brown we have seen some performance issues with the API, particularly with Pubmed ID lookups, but these issues are also present in the default interface too. Overall it's been quite rewarding to have control over the link resolver interface and to dive in and add new features that make it easier for patrons to get to library content.
This post describes a demo application that serves as a front-end to the 360Link OpenURL resolver from Serials Solutions. The code is available on Github and the application is running on Heroku.
A recent thread on the Code4Lib mailing list discussed technical details of the 360Link OpenURL resolver. The technical details are interesting because the OpenURL resolver is often the last handoff from the library systems to the location on the web where users can actually get what they are looking for. If something goes wrong, it's a frustating experience for everyone involved.
Over the last year, my colleagues and I at Brown University Library have developed a new front-end to 360Link using the 360Link API. It's been serving OpenURL requests since February and, as of August, has completely replaced our use of the default 360Link interface. The main objective of this project was to streamline the delivery of content found in various databases.
Since 360Link is rather popular in academic libraries and other libaries might be interested in implementing their own front-end, I decided to put together a demo Django application that uses the API to create a basic link resolver.
Here are a few sample links. You can also paste an OpenURL into the form on the index page
- Sample article lookup
- Pubmed lookup
- JSON(P) responses via content negotiation or adding output=json to the OpenURL.
- Another sample response but a customer code has been added to the url to switch to another library's API.
You can easily switch libraries by adding another library's Serials Solutions customer code to the URL - e.g Brown's default 360Link interface is at http://rl3tp7zf5x.search.serialssolutions.com/ so the customer code is "rl3tp7z5x". While testing this, I noticed that some library's API requires authentictation but most seem to be open and testable.
To run some real requests through this app, you could login to Mendeley and set it as your resolver in the “Find this paper at” dropdown menu.
The app is running on Heroku and the code is on Github. As far as I know, any library that subscribes to 360Link also has access to the API, so you could checkout this code, make a few tweaks, and have it running for your library pretty quickly. If you take a look, you'll notice that it's a couple of URL routes and a few dozen lines of controller (view in Django) code. So it takes less work to get started with the API than you might suspect.
For more details about working with the API, Daniel Talsky did a nice job of explaining the API in Issue 4, 2008 of the Code4Lib Journal.
At Brown we have seen some performance issues with the API, particularly with Pubmed ID lookups, but these issues are also present in the default interface too. Overall it's been quite rewarding to have control over the link resolver interface and to dive in and add new features that make it easier for patrons to get to library content.