Today, no self-respecting software vendor would even consider starting a new online service without an API. An Application Program Interface (API) is like the internet for online services. It enables applications to communicate with each other, transparently sharing and managing mission critical information 24-7. A good learning management system (LMS) needs this capability just as much, if not more than any other online service.
What does an API do?
The API is a software program that provides a door way to data stored on its server. It allows other software programs, client apps to communicate and share data with it. Given the nature of this communication it is essential that APIs obey all the rules related to cyber security. Unless the information is public and non-sensitive in nature data transfers must be authenticated and encrypted. Data transfers include:
The communication between client and server is guided by a published protocol or ‘contract’ between the parties. The vendor or owner of the API will publish an API document describing the “rules of engagement”, i.e. how to perform each of the data transfer operations described above. The vendor may not offer all the operations and may used different data protection strategies for each. For example, many public services do not require credentials to request data, but will only allow certain authenticated users to post, modify or delete data.
Why is this important for an LMS?
There are 3 important reasons an LMS might want to share data with client applications and an API is usually the most, secure, convenient and reliable way to do this.
Content authors, the people who create learning content, assessment tools and resources demand independence and flexibility in their toolsets, work location and hosting environments. Protocols such as the Sharable Content Object Reference Model (SCORM) was established in the late 90’s to address some of these concerns and later protocols xApi and cmi5 have built on those models. They enable the course author to develop content that can be reliably played on any compliant LMS. But it is the API that enables learning content and assessments to be exchanged between LMS environments. For example; Bluegem LMS has built-in SCORM capability and implements the SCORM Cloud API provided by Rustici Software. That gives course authors and customers the option to host content either directly in Bluegem or in SCORM Cloud. The same scenario could be applied to Moodle, Canvas or any other learning platform that supports an API. Likewise, Bluegem’s API enables learning management information, results and other student data to be shared with other online services.
2.Reporting
Reports, dashboards and data feeds all rely on APIs to provide up-to-the-minute, accurate and convenient information. Learning Management Systems are prolific users of reports. Reports feature in resulting, attendance, certification, grade books and completion rates. Bluegem LMS API provides data to address all of these requirements. One popular implementation is the use of Power BI dashboards to present and visualize training data in highly interactive and graphical business intelligence (BI) frameworks. In reporting contexts API’s only need to deliver information, i.e. client apps fetch data from the server but they don’t post of modify it. This lightens the security burden to some extent, but even for reporting, the prevention of unauthorized access to private and sensitive data is a number-one concern.
3. Integration
LMS platforms rarely operate in a stand-alone environment. In a corporate environment learner are also employees whose profiles exist in Active Directory, HR and ERP Systems. If the admin team for each system had to separately manage its own copy of each employee’s profile the potential for duplication, human error and inaccurate personnel records would be huge. API integration enables one system to act as the “source of truth” for specified data sets, while other systems can access and maintain the data in one place. Bluegem customers use the API to:
One of the biggest issues with Business Process Reengineering (BPR) in the late 90’s was the effect known as “Silo-ed Systems”, i.e. systems that are incapable of sharing data or working with other systems. APIs evolved mainly out of the need to address this issue, but as with so many transformative technologies, we are still learning all the ways they can and do help us to work more effectively in today’s world of high-speed transactions and interconnectivity.