@pekkanikander, thanks for the thoughtful and creative PR. It's really helpful to see how applications are using gcoap. In addition to this PR, I reviewed the PRs you created in the sock/nanocoap repository, #12 and #15. I also reviewed the application you are creating.

I see two issues here -- further development of gcoap resource handling, and ensuring access to coap_resource_t is const. The second issue seems straightforward, and I think should be addressed in a separate PR.

Read on for my thoughts on how to develop resource handling, and a potential implementation. Looking forward to further discussion.

Resource handler development

I see your PR developing the resource handler in two ways:

1. Map multiple parameterized paths to a single resource handler. Your example includes resources with final segments like A1, A2, A3, etc., which all use the same handler function.

2. Extend the resource type with resource-specific data, which is matched to the parameterized path and passed to the handler function. This data is passed by including the resource struct as a parameter to the function via the pointer-to-resource-pointer.

On the first point, I agree with your discussion with @kaspar030 of 'prefix handlers', where the last segment in a URL is considered a wildcard. gcoap's request handler would match on the prefix, and the final, differentiating segment would be available at runtime. The handler function then could adapt its response internally.

I think this approach provides nice advantages:

1. Compresses the definition of resources down to a single entry to match a single resource handler function.

2. Localizes parsing/handling of the incoming path. First the prefix is matched in the generic _handle_req() and _find_resource() functions. Then the final, parameterized segment of the path is mapped in the handler function.

3. The previous advantage reduces the need to extend the resource type with the parameter-specific data. The handler function can look up or otherwise provide the parameter-specific data without the need to define it in the resource struct.

Given the usefulness of prefix handlers, do we also really need to add data to the resource struct and pass the struct to the handler? I recommend we implement prefix handlers and see if there is a case for additional data. If there is such a case, I would advocate for making that data explicit in the coap_resource_t, maybe as a union of a void* and an int. I also would make the resource available to the handler explicitly as an attribute of the passed coap_pkt_t.

Prefix handler implementation

Below is an outline for implementation of prefix handlers.

(1). Identify a resource with a wildcard segment

Use an asterisk in the resource definition to indicate a final wildcard segment, like:

/foo/*

As you say in nanocoap #12, this idea could be extended so a search for a path with a specific final segment would be preferred. In other words, there could be two resources, with paths like:

/foo/*
/foo/bar

The second resource is preferred when exactly matching that URL. In any case, gcoap's _find_resource() function would be updated for wildcard handling.

(2). Add a function in nanocoap for the handler to retrieve the differentiating segment of the request url, like:

ssize_t coap_get_url_segment(coap_pkt_t *pdu, unsigned index, char **segment)

where the segment parameter is the address of a char* variable from the sender, and the return value is the length of the segment. This function uses the coap_pkt_t url attribute parsed out of the incoming request buffer.

(3). Store the differentiating segment/parameter in an observe request. We can add an attribute to gcoap_observe_memo_t, with a macro for the maximum length of the segment to store, like:

char url_param_segment[GCOAP_PARAM_SEGMENT_MAXLEN];

The value would be populated when the resource for the observe request includes a wildcard.

@pekkanikander @kb2ma how do we proceed here: continue? close? have someone to take this work up?

What is the current status of the nanocoap and g_coap rewrite? Sorry that I haven't been following. If that is stable now and committed, I could have another look at this and rewrite.

AFAIK a lot of bugfixing and rework is going on. @kb2ma can explain better.

#8513 added an opaque pointer attribute to the resource, and this pointer is available as a parameter to the handler function. Does that cover what is requested here?

@tcschmidt @kb2ma I'm planning to have a look at this on the forthcoming week.

I checked this. This now boils down to simply making the coap_resource_t references to const. This is now updated to master and seems to compile. However, I haven't done any extensive testing beyond compiling.

Glad to hear we're almost there. I'll give it a try.

@kb2ma Removed the type casts as you requested. Also rebased.

Thanks for seeing this through, @pekkanikander. Looks good to me.