Join GitHub today
GitHub is home to over 28 million developers working together to host and review code, manage projects, and build software together.Sign up
Flexible API STandard for E-content NISO (FASTEN)
The Problem of APIs
- Too much time to code for each individual provider
- Each vendor has its own technology roadmap and release schedule
- Each vendor has its own terminology/semantics (request/hold checkout/download) and its own API
- Some provide re-download links; some don’t
Goals for the FASTEN Working Group
- Create base set of Functional APIs to be used as needed by vendors and library developers for integrating with various Library systems to deliver a singular user experience for accessing and managing e-content
- Create recommendations and best practice guide for developing APIs for e-content vendor integration.
History and Current Status
Starting from Queens Library API Requirements Document For e-Content Partners, last year the working group made up of representatives from vendors, publishers, librarians, and consultants, broke out into three subgroups, Library User Interface, Library Discovery and Search, and Library Business to address identified issues facing current API development and group them into a couple of different deliverables including a Recommended Practice Document and an API specification.
|Library UX||Interface Design||Recommended Practice||Intuitive, clean, consistent interface design. Use familiar, widely implemented control features when possible (hamburger icon, play button, etc). Search and Discovery should be easy to use. User should organically recognize they are in “browse” mode (with the ability to sort or filter media on screen) and also initiate keyword/advance searching informed by visual cues in the interface.play media|
|Library UX||Accessibility||Recommended Standards||Elements in an interface (web, mobile, custom machine) should comply with UX best practices for disabled users, users with limited range of motion, and limited vision within reason. Should comply with Section 508/Web Accessibility Guidelines https://www.w3.org/TR/WCAG20/ e.g W3C’s Core Accessibility API Mappings 1.1 & HTML Accessibility API Mappings 1.0|
|Library UX||User Authentication on Providers||Recommended Standards||Library should seamlessly do handshake back to vendors to validate user account and set security protocols, including enforcing library rules and practices for audience controls. Whether by OAUTH2, SAML, Shibboleth etc|
|Library Business||Access restrictions||Recommended Standards||How to handle access restrictions, particularly in an academic, consortial, and/or multi-consortial environment|
|Library Business||Patron access of eContent from logged-in library page||API Specification||The ILS (or discovery layer) should be able to construct a URL which will deliver a logged-in patron directly to a logged-in session on the eContent vendor's site, either to the eContent "home", or to a specific title.|
Recently, the working group is exploring collaboration with the BIC committee on overlapping work between the two groups. Finally, the working group just created four subcommittees to finish the deliverable for the FASTEN Working Group, an Introduction group, a Recommended Practices group, a Recommended Standards group, and finally an API specification group.