Note:

If you want to create a new page for developers, you should create it on the Moodle Developer Resource site.

Errors handling in web services: Difference between revisions

From MoodleDocs
Line 32: Line 32:
===Format ===
===Format ===
The warning format is different following the protocol. It can be JSON or XML. REST/SOAP/XMLRPC all got different XML format. However they all implement the following structure:
The warning format is different following the protocol. It can be JSON or XML. REST/SOAP/XMLRPC all got different XML format. However they all implement the following structure:
<code php>
<code xml>
list of (
    object {
        'key' string  //the key can be matched by the client developer
                        to find out what kind of error happened and implement a specific behavior against this error.
                        For example: "userdoesntexist"
        'debug' string  //a not translated debug message to help the client developer to
                          know straight away what is the issue
        'elementsdesc' string  Optional //explaination of the elements. For example:
                                        "elements is an array containing the missing user id"
                                        "elements is a list of failing course id" or
                                        "elements is an array(context, component, area, itemid) - the failing grade" or
                                        "elements is a list of non existing course/category
                                        like (courseid1, categoryid1, courseid2, categoryid2...)"
        'elements'  //list of element
            list of (
                string/id/boolean/... (primary type)
            }
 
 
/**
/**
   * Creates a warnings external_multiple_structure
   * Creates a warnings external_multiple_structure
  * @return external_multiple_structure
  * @since  Moodle 2.3
  */
private static function warnings() {
    return new external_multiple_structure(
      new external_single_structure( array(
              'key' => new external_value(PARAM_ALPHA, 'the key can be matched by the client developer
                                  to find out what kind of error happened and implement a specific behavior against this error.
                                  For example: "userdoesntexist"'),                 
              'debug' => new external_value(PARAM_TEXT, 'a not translated debug message to help the client developer to
                                  know straight away what is the issue'),
                      'elementsdesc'  => new external_value(PARAM_TEXT, 'explaination of the elements. For example:
                                "elements is an array containing the missing user id"
                                "elements is a list of failing course id" or
                                "elements is an array(context, component, area, itemid) - the failing grade" or
                                "elements is a list of non existing course/category like (courseid1, categoryid1, courseid2, categoryid2...)" '),
              'elements' => new external_multiple_structure( new external_value(PARAM_RAW, 'an element can be used
                                by the client developer implements some automatic code fixing on the client side')),
          ), 'warning'), 'list of warnings'
  );
}
</code>
</code>



Revision as of 04:09, 1 May 2012

Exceptions

Format

Exceptions are caught by the server that generate its own error format. All exceptions contain a translated message + debuginfo.

REST-XML

<?xml version="1.0" encoding="UTF-8"?> <EXCEPTION class="invalid_parameter_exception">

   <MESSAGE>Invalid parameter value detected</MESSAGE>
   <DEBUGINFO></DEBUGINFO>

</EXCEPTION>

REST-JSON

SOAP

XML-RPC

How to handle exception on the client side

When to send an exception on the server side

  • DB WRITE functions must rollback when an exception is raised. We usually throw back the exception to the server.
  • Example: the user does not have appropriate access rights to call the function)

Warning messages

Format

The warning format is different following the protocol. It can be JSON or XML. REST/SOAP/XMLRPC all got different XML format. However they all implement the following structure: list of (

   object {
       'key' string   //the key can be matched by the client developer
                       to find out what kind of error happened and implement a specific behavior against this error. 
                       For example: "userdoesntexist"
       'debug' string   //a not translated debug message to help the client developer to 
                          know straight away what is the issue
       'elementsdesc' string  Optional //explaination of the elements. For example:
                                        "elements is an array containing the missing user id" 
                                        "elements is a list of failing course id" or 
                                        "elements is an array(context, component, area, itemid) - the failing grade" or
                                        "elements is a list of non existing course/category 
                                        like (courseid1, categoryid1, courseid2, categoryid2...)"
       'elements'   //list of element
           list of ( 
               string/id/boolean/... (primary type)
           }


/**

 * Creates a warnings external_multiple_structure

How to handle warning on the client side

When to send a warning on the server side

Most of the time you send warning in get_xxx() functions.

  • Example: the user is requesting information for a list of courses and one of those courses in no longer available