conventions are good

It has been a while since I last blogged, so ... hello and nice to see you again ! Yesterday I was allowed (and very privileged) to help Paul Hermans build a Linked Data Server for the Dutch government.

There's a more than natural match between NetKernel and Linked Data. Data transformations (aka transreptions) are bread-and-butter, the RESTOverlay makes mapping of the internet facing URLs pretty easy and dynamically building SPARQL queries is a breeze with a tool like the Text Recursion Language.

Now, I don't know if Paul noticed, but about ten minutes into our day, this error started popping up (in the console and cron log) : 
HDS Space Aggregation Failure, response to [res:/etc/system/CronConfig.xml] of type [java.lang.String] from [urn:com:proxml:stelselvanbasisregistraties:server] not transreptable to HDS

Strange because there's no res:/etc/system/CronConfig.xml resource in the module. I let it rest as it didn't impact the actual functionality and I needed all my brain capacity to understand all the Linked Data requirements.

This morning however I did the actual test and used the Request Resolution Trace Tool to see what happened :

Oops ... it does resolve.  Ok, what is going on here ?

• Dynamic Imports. A powerful capability of NetKernel. By adding a certain resource to your module (for example res:/etc/system/CronConfig.xml or res/etc/system/SimpleDynamicImportHook.xml), a relevant space of your module gets imported elsewhere. Of course, linked to this is a mechanism of finding these resources, which is called Space Aggregation.
• A wide RESTOverlay. Since the Linked Data server was to serve a whole domain, I used <basepath>/</basepath>.
• <auto404/>, another feature of the RESTOverlay, automagically returning a 404 resource if a request into the RESTOverlay fails.

While I had covered all bases for incoming requests through the Frontend Fulcrum, I hadn't even thought about internal requests that might get through to the - widely open - RESTOverlay.
 
The solution is very simple, add a Limiter endpoint before the RESTOverlay that catches all unwanted internal requests : 

        <endpoint>
            <prototype>Limiter</prototype>
            <grammar>res:/etc/system/
                <regex type="anything"/>
            </grammar>
        </endpoint>

And this is where a convention actually comes to my rescue. In theory, there's no way of knowing what internal requests are going to try and spam my RESTOverlay. However, convention states that Dynamic Imports and such work with res:/etc/system/.* resources.


It going to be the hottest day of the year here today (35+ Celcius), so I'm off to a place with some shade now. Enjoy your weekend !

P.S. No, haven't forgotten about the CRUD server and all. Working on it, watch this space !