@pekkanikander Would "prefix handlers", whose path ends in '/' and which handle a whole subtree, serve your needs?

Prefix handlers would probably cover a part of the use cases that can be handled with the mechanism I implemented. A lot depends on what parameters such a prefix handler would get. But in any case, such prefix handlers would be a very welcome addition. Especially if the handler search algorithm is changed so that you can first have a few special case handlers and then a prefix-handler as a default.

Never mind this comment below. It looks like I'm finding a better solution to the observe problem.

@kaspar030 I am now implementing also observe functionality, using gcoap. It would again be beneficial to extend coap_resource_t, to contain not only the handler but also an observe "handler," i.e. a function that may be called to construct and send an observe notification.

Given this, I started to contemplate that maybe the coap_resource_t type should be made "inheritable." As the resources are compiled into a table, such "inheritance" is not exactly trivial in C....

An alternative would be to extend the coap_handler_t signature to also take a function pointer as an additional parameter. That new function pointer parameter would have the same signature as coap_reply_simple. When the handler is called from a request context, it would be passed the coap_reply_simple. When called from an observe notification context, it would be passed a new function, coap_notification_simple. Of course, the handler could ignore that function pointer.

Or the coap_handler_t could be passed an enum that tells it whether it should construct a reply, a notification, or perhaps something else. That enum could be extended. But so could also the above function pointer. But such an enum would leave more freedom for the handler writer.

Given the experience so far, this way of adding a void * parameter to coap_handler_t does not make that much sense. It is better to add a const coap_resource_t * parameter to the coap_handler_t. That will be a much less intrusive change. I will implement that next. If that works, I will then make another pull request and close this one. This can then work as an archive of the discussion.

Closing in favour of #15.