Note:

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

Talk:Web services

From MoodleDocs

general remarks about OUTPUT of operations:

Is true of false informative enough ? Should the API have some sort of "last_error" function giving back more details such as "non existing course, non existing user, duplicate entry ...) Shall we consider that affecting a role that already exist or removing role that do not exist as an error (output=false) or not (output=true)

yep, agree, I'd result always one well defined $result object, with his status, error code and error msg (and perhaps, the whole original WS request encapsulated for easier debugging).
Eloy Lafuente (stronk7) 19:55, 21 December 2007 (CST)

I agree but throught the WS we need to be be carefull with the feedback we give to errors, due to security issues. --Ludo (Marc Alier) 14:14, 22 December 2007 (CST)

some WS to be able to... build courses ?

Perhpas it would be a great idea to start thinking about some WS functionalities like this:

  • add_course, delete_course, reset_course
  • add_section, delete_section, show_section, hide_section
  • add_activity, delete_activity, show_activity, hide_activity

Apart from the WS utility itself: automated creation of courses... it would help (or force, as we prefer), to better encapsulate course/section/modules internals, 100% isolating the creation and configuration from the frontend (forms, WS...). It implies some decisions, like upwards compatibility of old modules (although I think it can be maintained)... and so on, you know.

Just one idea to analyse. But with benefits in the end, IMO. Eloy Lafuente (stronk7) 20:02, 21 December 2007 (CST)

I do agree with this ; this would also allow creation of specific courses, customized for some users, depending of their "performances" in external evaluations methods ; when the ePortfolio API will be finalized in Moodle core's, accessing the portfolio of any user would be needed. Patrick Pollet 04:21, 30 December 2007 (CST)

the problem of ID of entity to fetch:

In the list of API calls defined in this page, Moodle entity to process (user,course,grade,event ...) is identified by an ID, that is implicitly the Moodle's internal id field used in the database. This raises a problem since it is very likely that in the "external SIS" talking to Moodle across the Web Service, the entity will be identified by another attribute such as an idNumber (user,course), a short name (course) or even an username (login of user).

So either we must provide :

  • extra API calls to convert external identifiers to Moodle's internal id, such as user_id_from_idnumber, user_id_from_username, course_id_from_shortname ..., at the cost of extra calls before the real one ; three calls would be needed to enrol student "CS2121212", to course "JAVA_101".
  • extra API functions such as delete_user_byusername, get_course_by_idnumber , enrol_student_byidnumber_tocourse_byshortname ....
  • or add parameters to the current API calls specifiying what identifier we are using such as delete_user(id,idField) with idField being a string that could be "id","idnumber","username","email" ... or enrol_student(sid,"idnumber",cid,"shortname") . This is the approach in the current SOAP implementation (with some calls of the previous type (get_user_byusername()...)

Patrick Pollet 04:21, 30 December 2007 (CST)

output of operations: adding URLs?

In addition, I suggest to return the full URL towards every Moodle entity, either added or got.

Today, in my uPortal installation, I request for Moodle database and display a list of courses in which the connected user is enrolled. Of course I provide links to these courses so that he can directly access. In addition I display a list of the last changes in these courses, again with links to the resources/activities.

If the URLs are returned by the WS then the calling service has nothing to know about Moodle URLs. Else it has to build every URL by aggregating Moodle alias + adequate PHP script + entity ID