We have already taken a look at how Moodle is highly modular, which guarantees extensibility and adaptability. We also mentioned that Moodle can be connected to other Moodle instances or Mahara and Totara Social—we will cover this in Chapter 16, Moodle Networking. Now, we are going to look at the integration of Moodle with other external systems via web services.
After providing a brief overview of web services and giving some application examples, you will learn about the following administrative topics:
We will not cover any programming aspects of web services as this is not an administrative task. You will find some good documentation for users and developers at https://docs.moodle.org/en/Web_Services.
It has always been possible to extend Moodle via code (PHP and JavaScript). Due to Moodle's open source code base, there can be no limitation to what code a developer is able to modify or extend. For you as an administrator, this was not a satisfactory situation, as you have no control over what parts of Moodle are being changed and, equally important, what data is being accessed or altered.
Moodle has a number of APIs that provide an abstract layer for certain functionalities. Examples of this are the Portfolio API, Repository API, and the File API. These are great for programmers as they reduce the amount of code that has to be re-written. In addition to these interfaces, Moodle also provides us with an ever growing number of web services.
Why would we want this? Well, there are three main scenarios we can think of:
Why do you as an administrator have to care about web services when they have been designed for developers? Well, that's the other big advantage of web services. The administrator has the ability to control which system is allowed to talk to your Moodle system and which service these systems are allowed to use. This way, you can control who has access to your system and limit what they can do.
3.143.247.125