Support Restlet attachment instead of Resource in Restlet Web Service Plugins

[Enet4]

At the moment, restlet-based plugins are made by implementing a ServerResource and giving it a relative path. However, sometimes it would be more adequate to create a hierarchy of resources from that root, while still taking advantage of Restlet's URI templates. Using a router is the most trivial thing to do:

Router router = new Router(getContext());
router.attach("/items", ItemsResource.class);
router.attach("/items/{itemName}", ItemResource.class);

But right now we cannot attach this router restlet into Dicoogle. This could become critical when implementing services with the likes of WADO-RS, which would be nicely represented with templates (e.g /studies/{StUID}/series/{SeUID}/instances/{InUID}/frames). WADO-RS itself is part of the core, but other developers would prefer to have this.

Restlets are also much more powerful than simple Restlet server resources, allowing developers to create their own converters, for example.

[Enet4]

Here's a proof of concept. It demands a change to the SDK, unfortunately.

[bastiao]

as already discussed before, it is possible to implement the abc/def/{serviceName} with our SDK without any problems at the moment. Just using toString and doInit().
Nevertheless, it maybe a good solution to have the feature requested in the issue.

And your proposal seems to keep the other methods anyway (adding ServerResource). Do you know any potential issues of that branch (despite of changes in SDK)

[Enet4]

as already discussed before, it is possible to implement the abc/def/{serviceName} with our SDK without any problems at the moment. Just using toString and doInit().

Pattern matching works, but Restlets contain a few more capabilities than routing. Converters are an example of a useful feature. Adding this up with the currently tricky integration of restlet server resources, I believe we should definitely support this.

And your proposal seems to keep the other methods anyway (adding ServerResource).

Actually, the intention is to keep server resource provision as deprecated from the moment we ship this feature, and to remove that method entirely in the following major version. This would give developers some time to push their server resources into restlet plugins.

Do you know any potential issues of that branch (despite of changes in SDK)

The PluginSet interface was modified to include a getter for the Restlet plugin interfaces. This will break compatibility with existing plugins. There are ways to alleviate this, but they all have their consequences. We could apply the idea in #115 and never face such issues again, with the cost of having to implement it and refactor all of our plugins in that moment. Another alternative is to move the source to Java 8 and give the getters in PluginSet a default implementation.

[Enet4]

As the proof of concept was built 5 years ago, it may be best to just rewrite it. I propose that we do not make this a blocker for 3.0.0. But if we keep the old ServerResource capabilities and give the new features a separate getter, this could still make its way into a minor version of Dicoogle 3. We do not expect SDK users to implement the Dicoogle platform proxy.