Show Advanced KnowledgeHide Advanced Knowledge

REST Service

1 Description

At the Hochschulrechenzentrum (HRZ) of the Philipp University of Marburg, we are using a REST interface which is implemented in-house as an ILIAS Plugin for a variety of purposes. Such purposes include an appropriate integration of the ILIAS LMS in our specific IT landscape, e.g. the ability to perform administrative tasks, such as the management of data container within and between different ILIAS instances and other systems.
The plugin has been made available for everyone of the ILIAS community as open source software at Github.com (see link below).
 
https://github.com/hrz-unimr/Ilias.RESTPlugin
 
Its core features are:

• Extensibility. This is done by a modular architecture based on the SLIM REST framework.
• Secureness. A permission system that controls access to (an possibly evolving) API for various REST clients. This is done by an implementation of OAuth2 (RFC6749) including Bearer Tokens.
• Personalizable. using the internal role based system, operations on resources can only be applied for users which have the appropriate permissions.

A REST Plugin might be suitable for special custom tasks but for new ILIAS features like xAPI, REST based SCORM Tracking, Workflow-Engine and Mobile Middleware etc a REST Service must be part of the core. Here we should discuss how we can achieve an implmentation of a sustainable REST Service. Some of the plugin features may be adopted, others have to be newly created.

1.1 AK, 19 Feb 2014

As written in the JF comment, we need to make some general architecture decisions first. After that we should start a rest service. I hope we are able to get a first prototype ready for 4.5. Some points:

• We need a strategy to decentralize controllers into the the different components. Typically components register things in their service.xml/module.xml files. 15 Sep 2014: Max made a proposal for a service discovery concept in the Workflow Engine SIG.
• For the authentication, I would like to Stefan to work out some concept. Supporting different methods like basic auth or certificates definitely makes sense.
• We need a good way to re-use code that is already used in the usual web-front-end scenario. E.g. permission checking, parameter validation, and "use case / interaction" logic. This should not be part of rest controllers. They should only include logic related to the handling of rest-requests and responses. This is the main architecture part.
• I am not sure if we need a WSDL-like spec of the whole interface. The request and response structures must be well-defined and documented. Something like JSON Schema, see also this page. 15 Sep 2014: Again the use of Service Discovery and ADT concepts should be helpful here.
• We need a versioning of the api, something like /rest/v1/... /rest/v2/... should be sufficient
• We need implementation guidelines for the different REST verbs. Do we only use GET/POST? What would it need to make use of PUT/PATCH/... (I didn't check it, but at least PUT should be possible)

2 Additional Information

• Idea / concept: Stefan Schneider, Universität Marburg (schneider@hrz.uni-marburg.de)
• Funding: Required
• Maintainer: tbd
• Development: Feature is to be developed by tbd
• Test cases: tbd

3 Discussion

JF 20 Aug 2012: A general REST interface brings up some questions on the ILIAS architecture that we would like to adress in a workshop of the developers. We started to make developer meetings of the core developers in April 2012. We will schedule a next meeting after 4.3 is stable and propose to make the architecture the main topic. Stefan, we will contact you and invite you to the meeting.

MB 14 Mar 2014: The Introducing Workflow Engine can be extended to offer RESTful webservices. I strongly support a REST Service that allows for modular extension and that supports "industry-common" lightweight authorization.

JF 15 Sep 2014: We support the idea to move forward with a general REST service for ILIAS 4.6. We will continue to discuss the technical details. Since xAPI will not be ready for 4.5, xAPI may be based on a general REST solution, too.

4 Implementation