REST-API for Java-Service

1 Summary

2 2 Problem Statement

The Java backend services (lucene search, certificate generation) currently rely on an outdated web service protocol (XML-RPC). The XML-RPC implementation uses a built-in minimal webserver that provides basic HTTP transport without modern security features. The embedded webserver does not support standard TLS termination, making secure HTTPS communication challenging to implement. Additionally, there is no maintained PHP library available to implement an XML-RPC client.

3 Concept

The migration replaces the XML-RPC architecture with a REST-based solution built on Spring Boot. The application uses an embedded webserver (Jetty/Tomcat integrated into a JAR file) so no external server is required for initial deployment.

An external webserver (Nginx/Apache) can be added later if needed for TLS termination or load balancing.All REST endpoints are documented using OpenAPI. An ILIAS PHP client library is generated from the OpenAPI specification using openapi-generator.

4 User Interface Modifications

4.1 List of Affected Views

{ For all screens that should be modified, newly introduced or removed, please list the title and breadcrumb of all affected views. }

4.2 User Interface Details

{ For each of these views please list all user interface elements that should be modified, added or removed. Please provide the textual appearance of the UI elements and their interactive behaviour. }

4.3 New User Interface Concepts

{ If the proposal introduces any completely new user interface elements, you might consult UI Kitchen Sink in order to find the necessary information to propose new UI-Concepts. Note that any maintainer might gladly assist you with this. }

4.4 Technical Aspects

{ Necessary technical information have to be provided here, e.g. dependencies on other ILIAS components, necessary modifications in general services/architecture, potential security or performance issues. }

5 Non-Functional Implications

5.1 Security

{ Does the feature include any special security relevant changes, e.g. the introducion of new endpoints or other new possible attack vectors. If yes, please explain these implications and include a commitment to deliver a written security concept as part of the feature development. This concept will need an additional approvement by the JourFixe. }

5.2 Privacy

{ Personal data that will need to be stored or processed to implement this feature have to be listed here. For each date give a short explanation why it is necessary to use that date. }

5.3 Accessibility Implications

{ If the proposal contains potential accessibility issues that are neither covered by existing UI components nor clarified by guidelines, please list them here. For every potential issue please either propose a solution or write down a short risk assessment about potential fallout if there would be no solution for the issue. }

6 Process Information

6.1 Involved Authorities

If this request is related to multiple components, please list both authorities for all related components.

6.2 Contact

Person to be contacted in case of questions about the feature or for funding offers:  {Please add related profile link of this person}

6.3 Funding

Funding status and funding parties are listed in the block 'Status of Feature' in the right column of this page.

If you are interested to give funding for this feature, please get into contact with the person mentioned above as 'Contact'.

7 Discussion

8 Implementation

Feature has been implemented by {Please add related profile link of this person}

8.1 Description and Screenshots

{ Description of the final implementation and the changed behaviour in the related components. Please add screenshots to visualise the changes if possible. }

8.2 Test Cases

Test cases completed at {date} by {user}

8.3 Privacy

Information in privacy.md of component: updated at {date} by {user} | no change required

8.4 Approval

Approved at {date} by {user}.