As third-level institution systems move increasingly towards favouring SaaS solutions, we are seeing increased requirements for effective and comprehensive APIs (Application Programming Interfaces) for data interfacing. Traditionally, a lot of this type of interfacing has been performed using direct database access.
Direct database access has various advantages particularly around simplicity and reliability - it is a tried and tested approach that has worked for decades. However, it also introduces very tight coupling between systems, introduces security and data access risks and can be brittle where target systems might change underlying database table structures.
APIs are mechanisms for enabling two or more software services to communicate with each other using a set of definitions and protocols. The principle is that these software services do not care what programming language or data structures are used at either end, as long as the method for communication is precisely defined.
With Guru Version 2.0, we are introducing a full suite of APIs for all Guru 2.0 services. These powerful APIs will allow institutions to have full, secured access to their own data. This access will provide read interfaces for any data contained within Guru and insert/update/delete functionality where appropriate. This will allow institutions to do anything they wish with their data, interface with third party systems, write bespoke systems consuming or updating Guru data etc.
As an example use-case - consider an institution who wants to create corresponding external examiner accounts in their virtual learning environment (e.g. Moodle, Blackboard). The external examiner biographical details exists inside Guru as the single-source of truth. The institution could then write some simple code to populate the VLE accounts with the information coming from Guru.In addition, the API would contain all of the module and programme codes assigned to the external examiner, so this could be used for populating external examiner access in the VLE.
The API call involved might look like the following: (with security of course!)
This will return a list of all of the external examiners in JSON format. This query can be further refined by introducing search filters to only select certain data.
The Guru API documentation will show exactly how the interfacing can be done, how to make the call, what data is expected to be returned etc.
For example, this might be the response back to your software system (demo in Insomnia/Postman)
We hope that this makes sense and that you are looking forward to this as much as we are!