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.

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)