Development talk:Web services - Revision history

Jamiesensei: New section: Using web services to allow client side code such as js, Flash/Flex or java to communicate with Moodle

2008-11-11T12:51:19Z

New section: Using web services to allow client side code such as js, Flash/Flex or java to communicate with Moodle

← Older revision		Revision as of 12:51, 11 November 2008
Line 60:		Line 60:
	Would it be possible to expand on the existing web service work rather than produce something completely new? We're investing a lot of effort with these services and we wouldn't like to have to re-do that work.		Would it be possible to expand on the existing web service work rather than produce something completely new? We're investing a lot of effort with these services and we wouldn't like to have to re-do that work.
	[/Feedback]		[/Feedback]

			== Using web services to allow client side code such as js, Flash/Flex or java to communicate with Moodle ==

			I understand these web services should also allow client side code to communicate with Moodle.

			I imagined that web services used by client side code should be authenticated with a 'session key'. When the server outputs a page with such an object in it then a random session key string should be created and passed into the client side code through the html that embeds/outputs the object in a page. I think the session key should be associated with a user and probably a Moodle context. Then the context can be used within block related code or activity module related code to know when for example the client side code passes a log message back to Moodle or when it passes a grade back to Moodle that the grade is for such and such an activity. For web services for Flash I thought an appropriate way to do this would be to have an array of objects of session keys and there associated context/other data in the $SESSION object.

Stevehurcombe: Implementation feedback

2008-01-15T15:49:49Z

Implementation feedback

← Older revision		Revision as of 15:49, 15 January 2008
Line 46:		Line 46:

	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		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

			== Implementation feedback ==

			[Feedback]
			Speaking as someone who will be using this API to integrate with another line of business application I would recommend the following changes.

			The add_user method should really be a 'SetUser' ie it will create the record if it does not exist or update it it if it does. The ID that is passed into the method would be our primary key which Moodle would use to recognise the user record within Moodle. We would not normally need to know anything about the Moodle primary key.

			One option to make the web services maintainable is to accept XML as a parameter and not a structure or custom object. That way you can define an XSD which will define required\optional parameters. Equally if you include a version number you can change the XML to add new features without having to redefine the web service signature itself (and hence clients will not have to recompile their code). So you may receive a SetUser call with XML V1.0 and another with XML V2.0 on the same webservice but from two different clients supporting different versions of the API.

			The method must accept an array of users - it's a little trickier to set this up in the client code but is much more scalable (if there's some good sample code then this is easier anyway). The latency (round trip time) with web service calls is high so you want to do as much as you can in a single call. We have a customer who wants us to deploy Moodle to 40,000 users - we're not going to do that using individual calls.

			Would it be possible to expand on the existing web service work rather than produce something completely new? We're investing a lot of effort with these services and we wouldn't like to have to re-do that work.
			[/Feedback]

Saint-georges: /* output of operations: adding URLs? */

2008-01-03T13:35:17Z

output of operations: adding URLs?

← Older revision		Revision as of 13:35, 3 January 2008
Line 45:		Line 45:
	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.		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 ~~not~~ to know about Moodle URLs. Else it has to build every URL by aggregating Moodle alias + adequate PHP script + entity ID		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

Saint-georges at 10:57, 3 January 2008

2008-01-03T10:57:56Z

← Older revision		Revision as of 10:57, 3 January 2008
Line 34:		Line 34:

	[[User:Patrick Pollet\|Patrick Pollet]] 04:21, 30 December 2007 (CST)		[[User:Patrick Pollet\|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.
			* user added with id 12345 --> http://moodle.xxx.edu/user/view.php?id=12345&course=1
			* got user 12345 --> http://moodle.xxx.edu/user/view.php?id=12345&course=1
			* course added with id 67 --> http://moodle.xxx.edu/course/view.php?id=67
			* got course 67 --> http://moodle.xxx.edu/course/view.php?id=67
			* etc.

			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 not to know about Moodle URLs. Else it has to build every URL by aggregating Moodle alias + adequate PHP script + entity ID

Ppollet: /* the problem of ID of entity to fetch: */

2007-12-30T10:27:38Z

the problem of ID of entity to fetch:

← Older revision		Revision as of 10:27, 30 December 2007
Line 27:		Line 27:
	So either we must provide :		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		* 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 ....		* extra API functions such as delete_user_byusername, get_course_by_idnumber , enrol_student_byidnumber_tocourse_byshortname ....

Ppollet: /* the problem of ID of entity to fetch: */

2007-12-30T10:25:52Z

the problem of ID of entity to fetch:

← Older revision		Revision as of 10:25, 30 December 2007
Line 27:		Line 27:
	So either we must provide :		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 ~~really~~ one		* 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

	* extra API functions such as ~~get_user_byusername~~, get_course_by_idnumber ...		* 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 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()...)

	[[User:Patrick Pollet\|Patrick Pollet]] 04:21, 30 December 2007 (CST)		[[User:Patrick Pollet\|Patrick Pollet]] 04:21, 30 December 2007 (CST)

Ppollet: /* the problem of ID of entity to fetch: */

2007-12-30T10:21:50Z

the problem of ID of entity to fetch:

← Older revision		Revision as of 10:21, 30 December 2007
Line 32:		Line 32:

	* 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 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" ..

			[[User:Patrick Pollet\|Patrick Pollet]] 04:21, 30 December 2007 (CST)

Ppollet: /* some WS to be able to... build courses ? */

2007-12-30T10:21:25Z

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

← Older revision		Revision as of 10:21, 30 December 2007
Line 20:		Line 20:

	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.		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.
			[[User:Patrick Pollet\|Patrick Pollet]] 04:21, 30 December 2007 (CST)

	==the problem of ID of entity to fetch:==		==the problem of ID of entity to fetch:==

Ppollet: question of identifier for Moodle's entity

2007-12-30T10:17:52Z

question of identifier for Moodle's entity

← Older revision		Revision as of 10:17, 30 December 2007
Line 18:		Line 18:
	Just one idea to analyse. But with benefits in the end, IMO.		Just one idea to analyse. But with benefits in the end, IMO.
	[[User:Eloy Lafuente (stronk7)\|Eloy Lafuente (stronk7)]] 20:02, 21 December 2007 (CST)		[[User:Eloy Lafuente (stronk7)\|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.

			==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 really one

			* extra API functions such as get_user_byusername, get_course_by_idnumber ...

			* 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" ..

Granludo: /* general remarks about OUTPUT of operations: */

2007-12-22T20:14:15Z

general remarks about OUTPUT of operations:

← Older revision		Revision as of 20:14, 22 December 2007
Line 5:		Line 5:
	: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).		: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).
	:[[User:Eloy Lafuente (stronk7)\|Eloy Lafuente (stronk7)]] 19:55, 21 December 2007 (CST)		:[[User:Eloy Lafuente (stronk7)\|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. --[[User:Ludo (Marc Alier)\|Ludo (Marc Alier)]] 14:14, 22 December 2007 (CST)

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