Best practice to create a custom python endpoint on SplunkWeb not Splunkd?

[sideview]

App developers can use restmap.conf to define custom REST endpoints on splunkd's port aka the management port (eg https://localhost:8089). However there doesnt appear to be any mechanism to use restmap.conf to do the same on SplunkWeb's port, (eg http://localhost:8000).

I know that I can get what I need by creating a custom UI module. (I can package a custom UI module in my app, custom modules can have python handlers, and that python will respond to requests at http://localhost:8000/en-US/module/system/Splunk.Module.MyCustomModule/render)

But I'm reluctant to create a custom UI module that is designed to never be used from the UI. Plus this would leave me no way to associate relevant capabilities with the endpoint, a security feature which restmap.conf does offer.

Is there a third way that I'm missing? ie is there a way to hit a restmap.conf endpoint from some proxied URL on SplunkWeb?

For instance: Splunkd's search API is all accessible from SplunkWeb via a little proxy that it has under /api/search: http://localhost:8000/en-US/api/search/jobs//results, so maybe some similar mechanism exists for endpoints created by restmap.conf ?

[melting · Accepted solution]

Sure you can create a custom endpoint in splunkweb (port 8000)

What you want to do is create a custom controller. This pretty similar to the python portion of a module. Take a look at the docs on splunkweb controller @ dev.splunk.com.

[sideview]

D'oh. Thanks melting. I totally forgot controllers went out in 4.2. I think they were less than totally documented, or at least I remember the practical suggestion was that the only way to figure out how to create my own in an app, was to reverse engineer one of the shipping controllers in the core product.

[melting]

This works in 4.2 as well.

[sideview]

Thanks melting. 4.3 didn't come out until Jan 2012 and this question was posted from back in the 4.2 days. In the end I had to create several custom modules and then use them only for their endpoints, which was a bit of a bummer. These days I am of course much happier with controllers! Thanks again.