This is a test site. Any changes will be lost!

Development:Moodle API: Difference between revisions

From MoodleDocs
Line 1: Line 1:
{{Template:Work in progress}}{{Moodle_2.0}}
{{Template:Work in progress}}{{Moodle_2.0}}
=Introduction=
=Introduction=
This document is about the Moodle API introduced in Moodle 2.0. In order to be available more widely, Moodle 2.0 relocates core functions into different api.php files, called Moodle API.<br>Thus, it would centralize core functions into known location reducing code redundancy, bugs and maintenance time. Moreover the new web services module will be able to provide all of these functions as services. <br>With the time going, more of the core functions should end up into Moodle API.
 
This document is about the Moodle API introduced in Moodle 2.0, which is intended to standardise and streamline methods for calling common control functions in Moodle core and modules.   This is most useful for web services (where external systems want to control Moodle) but also for alternative interfaces such as Flex and so on.
 
To do this, Moodle 2.0 relocates important functions into new api.php files within each module, with standard documentation and structure to help reduce code redundancy and maintenance, while improving readability and functionality.
 
Over time we expect more and more Moodle functionality to move into these files.
 
==Related documents==
==Related documents==
*[https://docs.moodle.org/en/Development:Web_services Web Services for Moodle 2.0]
*[https://docs.moodle.org/en/Development:Web_services Web Services for Moodle 2.0]
* TO BE DONE: create a tracker issue for Moodle API with subtasks for every api.php file
* TO BE DONE: create a tracker issue for Moodle API with subtasks for every api.php file

Revision as of 01:43, 6 November 2008

Note: This article is a work in progress. Please use the page comments for any recommendations/suggestions for improvement.

Moodle 2.0


Introduction

This document is about the Moodle API introduced in Moodle 2.0, which is intended to standardise and streamline methods for calling common control functions in Moodle core and modules. This is most useful for web services (where external systems want to control Moodle) but also for alternative interfaces such as Flex and so on.

To do this, Moodle 2.0 relocates important functions into new api.php files within each module, with standard documentation and structure to help reduce code redundancy and maintenance, while improving readability and functionality.

Over time we expect more and more Moodle functionality to move into these files.

Related documents

Implementation

Convention

A new api.php file should be created into each module/block folder, and also the current admin/user/course/... common moodle folders.
This file should contains a class named from the module:

   class mod_forum_api
   class user_api
   class course_api
   ...

Into this class, static function will provide requested information and operation:

   create_forum()
   get_user()
   get_content()
   get_discussions()
   ...

Standard function names

In order to manipulate object and to be consistent for all API, we recommend to use: get_xxx() //for retrieving one or more objects named xxx set_xxx() //for updating or creating one or more object xxx update_xxx() //for updating one or more xxx objects, throws an exception if the object doesn't exist create_xxx() //for creating an object, throws an exception if the object (primary key) already exist delete_xxx() //for deleting an object, TO BE DEFINED: throws an exception if the object doesn't exist

API functions must be defined/declared

The web services module needs to know what parameter are required and what information are returned. So we need a way to generate all these information.
TO BE DEFINED: have a look at PHPdoc if we can generate all needed information from the documentation. Then we cache it in a file. The web services module will look at this file in order to create a WSDL file for soap, in order to know what function are available in REST,...

Call the API functions

These functions are called inside Moodle by the modules, block and others plugin, and also web services module. As they are static function, they should be called as:

   mod_forum_api::get_discussions
   user_api::create_users
   course_api::get_course
   ...

Functions List

All following paragraph matches a Moodle folder. All described functions should be included in a class named from the folder path, into an api.php file.

admin

These API would be used in order to configurate Moodle.

blocks

blog

calendar

course

group

create_group($group) //$group is an array() create_groups($groups) //$groups is an array of $group get_group($param) //$param is an array() set_group($group) //$group is an array(id, ...) - id is required update_group($group) //$group is an array(id, ...) - id is required delete_group($groupid) //$groupid is an integer delete_groups($groupids) //$groupids is an array of group id

add_group_members($groupid, $userids) //$userids is an array of user id remove_group_members($groupid, $usersid) get_group_members(groupid) get_groups_by_course($courseid)

mod

assignment

chat

choice

data

feedback

forum

glossary

lesson

quiz

resource

scorm

survey

wiki

portfolio

repository

search

tag

user

create_user($user) //$user is an array(username, password, forcechangepwd, firstname,

                      //                  lastname, email, emaildisplay, emailactivated,
                      //                  city, country, timezone, language, description,...)

create_users($users) //$users is an array of $user get_user($param) //$param is an array(username, firstname,

                      //                  lastname, email,
                      //                  city, country,...)

set_user($user) //$user is an array(id, ...) - id is required update_user($user) //$user is an array(id, ...) - id is required delete_user($userid) //$userid is an integer delete_users($userids) //$userids is an array of $id