|
|
| (233 intermediate revisions by 14 users not shown) |
| Line 1: |
Line 1: |
| {{Moodle_2.0}} | | {{Template:Migrated|newDocId=/docs/apis/subsystems/external/description}} |
| | |
| == Purpose ==
| |
| This document explain how we describe the web service functions into Moodle 2.0.
| |
| We store web service descriptions into the external files (where the web service functions are located) and also into the database.
| |
|
| |
| * Web service database tables should only contain data that can be managed by administrator
| |
| * All the web services description should be in an array into each external.php file
| |
| * Moodle upgrade will browse all external files, check the description and update the database (if functions/services disappeared or are created)
| |
| | |
| === Administration pages ===
| |
| Moodle administrators will be able to enable services and functions. By default all services and functions will be disabled.
| |
| | |
| List of administration functionalities:
| |
| * enable a service => enable all the functions into this service
| |
| * enable a function => enable the services that the function is associated with. It does not change any other function status.
| |
| * an option will enable/disable all services
| |
| * an option will enable/disable all functions (into service settings page)
| |
| Administrators will also be able to create a custom service, selecting any existing functions.
| |
| | |
| ===external_functions table===
| |
| List of web service functions.
| |
| | |
| | |
| {| class="nicetable"
| |
| ! Field
| |
| ! Type
| |
| ! Default
| |
| ! Description
| |
| |-
| |
| | '''id'''
| |
| | int(10)
| |
| | auto-incrementing
| |
| |
| |
| |-
| |
| | component
| |
| | varchar(100)
| |
| |
| |
| | Component where function defined, needed for automatic updates.
| |
| |-
| |
| | '''name'''
| |
| | varchar(150)
| |
| |
| |
| | Name of function - Appears on the admin page
| |
| |-
| |
| | enabled
| |
| | int(1)
| |
| | 0
| |
| | function enabled, function might be disabled for security reasons - The only field editable by administrator !
| |
| |-
| |
| | phpfile
| |
| | varchar(255)
| |
| |
| |
| | location where function defined - Needed for identifying
| |
| |-
| |
| | contextrestriction
| |
| | int(1)
| |
| |
| |
| | extra information - some functions may support context restrictions
| |
| |}
| |
| | |
| | |
| Note about [https://docs.moodle.org/en/Development:Web_services_security#New_database_tables Petr Proposal]:<br>
| |
| * I don't think we need to insert a params description row as we have the params description into the description array.
| |
| * I removed requiredlogin because it can be inserted into the description array. The administrator should never change it.
| |
| | |
| ====New function: validate_context_restriction($currentcontext)====
| |
| | |
| Each functions that supports restrictions must:
| |
| # find out context of request from function parameters - when enrolling user to course it is a course context, when add post to chat it is chat context, etc.
| |
| # call validate_context_restriction($currentcontext) - Moodle verifies $currentcontext is equal or child of restriction context, if not exception is thrown and script terminates.
| |
| | |
| The restriction context is stored in some global variable which is initialized in lib/setup.php using data from token tables.
| |
| | |
| ===external_services table===
| |
| ''Service'' is defined as a group of web service functions.
| |
| | |
| | |
| {| class="nicetable"
| |
| ! Field
| |
| ! Type
| |
| ! Default
| |
| ! Description
| |
| |-
| |
| | '''id'''
| |
| | int(10)
| |
| | auto-incrementing
| |
| |
| |
| |-
| |
| | component
| |
| | varchar(100)
| |
| |
| |
| | Component where service defined, needed for automatic updates.
| |
| |-
| |
| | '''name'''
| |
| | varchar(150)
| |
| |
| |
| | Name of service (gradeexport_xml_export, mod_chat_export) - appears on the admin page
| |
| |-
| |
| | enabled
| |
| | int(1)
| |
| | 0
| |
| | service enabled, for security reasons some services may be disabled - The only editable field by the admin
| |
| |-
| |
| | custom
| |
| | int(1)
| |
| | 0
| |
| | Custom local service, created manually by admin or some other way (CAN BE updated automatically during the cron job => function not existing get removed). This field is useful if we want to implement an admin page where the admin selects some functions from a list of all external functions. Note: we probably need a button to desactivate all services in once.
| |
| |}
| |
| | |
| Note about [https://docs.moodle.org/en/Development:Web_services_security#external_services Petr's Proposal]:<br>
| |
| * I removed the ''version'' row. If we want to create a special version number for a service, we could probably write it in the description array (it's not going to be changed by a Moodle administrator, it doesn't need to be saved into the database). Otherwise we could also use the moodle version to have some kind of reference about a Web Service API version.
| |
| * I removed ''requiredCapability'' row because the capabilities are checked into the external functions. These checks are hard coded into the external function as anywhere else into Moodle.
| |
| * ''custom'' row can now be updated during Moodle upgrade.
| |
| | |
| ===external_services_functions table===
| |
| Specifies functions used by services.
| |
| | |
| {| class="nicetable"
| |
| ! Field
| |
| ! Type
| |
| ! Default
| |
| ! Description
| |
| |-
| |
| | '''id'''
| |
| | int(10)
| |
| | auto-incrementing
| |
| |
| |
| |-
| |
| | '''externalserviceid'''
| |
| | int(10)
| |
| |
| |
| | foreign key, reference external_services.id
| |
| |-
| |
| | '''externalfunctionid'''
| |
| | int(10)
| |
| |
| |
| | foreign key, reference external_functions.id
| |
| |}
| |
| | |
| | |
| === PHP array description ===
| |
| ====why a web service description ====
| |
| * in order to generate the WSDL for SOAP
| |
| * in order to generate documentation for protocol as REST or XMLRPC
| |
| * in order to clean automatically the params
| |
| ====code template ====
| |
| <code php>
| |
| | |
| $object = new object();
| |
| $object->property1 = PARAM_NUMBER;
| |
| $object->property2 = PARAM_ALPHA;
| |
| | |
| $params = new object();
| |
| $params->objects = array($object);
| |
| $params->object = $object;
| |
| $params->primarytype = PARAM_ALPHANUM;
| |
| | |
| $return = new object();
| |
| $return->values = array(PARAM_NUMBER);
| |
| $return->value = PARAM_NUMBER;
| |
| | |
| $this->descriptions['function_name'] = array(
| |
| 'service' => 'service_name',
| |
| 'requiredlogin' => 0,
| |
| 'params' => $params,
| |
| 'optionalinformation' => 'Human readable text: "object" and "primarytype" parameters are optionals',
| |
| 'return' => $return );
| |
| </code>
| |
| | |
| === Way to fill the database tables ===
| |
| The Moodle upgrade will take care of the updates. We will need to add a function into lib/upgradelib.php/upgrade_plugins() that will check all web service description.
| |
| | |
| === Return values are filtered by the servers ===
| |
| Web service function should be able to return whatever they want. Each server should be looking at the web services description and returns the expected values.
| |
| | |
| == Petr's Proposal ==
| |
| It can be found [https://docs.moodle.org/en/Development:Web_services_security#New_database_tables here].
| |
| | |
| [[Category:Web Services]]
| |
