code.uoa.gr

Limesurvey XMLRPC/JSONRPC API

National Kapodistrian University of Athens (NKUA) in 2011 decided to replace the various courses evaluation methods followed by each school, with a Central Survey Service that will facilitate a common methodology and establish common metrics across the university.

It was a challenging endeavour, not only because of the complexity of the functionality required for the evaluation framework, but also due to the breadth and complexity of the organization it was addressing. Being the first and one of the biggest Greek universities, NKUA has more than 2.000 faculty members and 50.000 students and offers nearly 2.000 undergraduate courses across 33 schools.

To make the long story short, either due to cost or scalability issues, we decided to drop clickers and scanners as tools to gather students’ feedback. Online questionnaires proved to be the best solution for us.

We decided to go with Limesurvey as it had a good track record of deployments, it was widely used in academia and above all it was open source software. The advantage of an open source based solution was the fact that it would allow us to adapt it to our needs both in terms of integration and functionality and hopefully contribute our work back to the community.

XML-RPC/JSON-RPC API the Importance of interoperability

With HTTP being the TCP layer of the new web era the WebServices and interoperability between applications becomes of paramount importance. Nowadays most web applications need a properly designed API to support Application to Application -or B2B if you prefer- communication and the rationale of our architecture is a good example of this.

The design of our solution was driven by the following principles and constrains:

  • The big number of surveys made a centralized management approach impractical and resource heavy. On one hand the creation of each survey upon user request from a central team requires an ongoing effort and on the other hand the creation of all surveys in advance is a waste of resources since a fraction of them might be used.

    Hence, online surveys should be offered as a self-service tool seamlessly integrated with a) the Courses Catalogue, b) the Courses Enrolment and c) the Faculty and Students directory to ensure surveys’ auto provisioning and service consistency.

  • Limesurvey’s Management Web Interface was not appropriate for use by our target audience (Faculty members and Schools’ Quality Assurance committees) as it was too complex and tailored for different type of users (statisticians and survey experts).

  • Limesurvey could not accommodate the access policies required in the context of a Central Survey Service for courses evaluation in terms of access granularity and users’ roles. An extra isolation layer is needed both for security reasons but also to implement specific business rules and workflows such as “who has rights to launch a new evaluation survey and when”, “who has access to survey’s results and when” etc.

  • Avoid radical changes in Limesurvey’s core design in order to maintain compatibility with the main release. Instead take advantage of the software evolution and contribute with our own focused enhancements.

With all these in mind we concluded on three layer architecture:


RemoteControl2 Diagram
  • the first layer is the Limesurvey2 core software which provides the survey engine
  • the second is the Limesurvey2 RemoteControl which provides the Web Services API
  • the third layer is a series of home-grown Web Applications that require some sort of survey, voting, polling or quiz functionality either as part of its core logic or as supplementary features. These Web Applications can exploit the functionality offered by Limesurvey2 without having to implement everything from scratch.

So coming back to our initial goal, i.e. building NKUA’s Central Survey Service for courses evaluation we realized that a complete and functional Limesurvey2 Remote Control is crucial if we wanted our new Web Application to fit into the architecture described above.

However at the time of the design of the Service, the API in Limesurvey2 wasn’t fully implemented by the main development team, thus we decided to implement the missing parts and enrich it with those functionalities that would be essential to any development team using the API.

On conclusion of the implementation, the code was contributed back to the main branch, and it is currently a vital part of the LimeSurvey application. Moreover, the NKUA's development team is actively involved in the Limesurvey application, mainly by supporting, maintaining and building new features for the Remotecontrol2 API.

Design Principles

So far we have tried our best to follow best practices on Web Services APIs.

Specifically we paid extra attention on the following design principles:

  • Leverage functions and methods that already exist in the core software without exposing implementation specific details
  • Do not add new features; instead make existing features available to 3rd party software in a structured and sufficiently powerful way
  • API should be easy to use. We like APIs that can be used in an obvious way with minimum reading. We hate APIs that haven't been properly documented.
  • Good names drive development. We tried to use self-explanatory names and stay consistent with name semantics throughout the API.
  • Performance matters and security matters. This will be our focus in the next iteration. Input validation will be one of the issues to be addressed.

We also tried to adhere to certain guidelines defined in the LimeSurvey developer’s documentation.

The code is in git-hub and is being constantly synced with the LimeSurvey github project so as to avoid conflicts. It is publicly available at Github.