Today I described the gcoap API at the Thing-to-Thing Research Group meeting [1]. Of course, any description of gcoap also includes nanocoap, the lower level API on which gcoap depends. A question was raised at the meeting to evaluate the relationship between the two and how they can evolve together.
Relationship: I created a wiki page some time ago on the big picture approach for gcoap and provided some contrast with nanocoap [2]. You can also read how the relationship got started [3]. When adding a feature to gcoap, I always debate the featureful vs. resource-use tradeoff. I find it helps that nanocoap has gcoap's back as a more constrained implementation.
So from my perspective, the two implementations target different uses, and the relationship works OK. To date, nanocoap has not developed much from the original implementation. It has helped gcoap to have a stable base, but some issues and PRs have not been addressed either.
Evolution: From gcoap's perspective, I see a change coming to it's API. It needs another function between the "_init()" and writing the payload to provide options for the message, maybe "gcoap_init_opts()" [4]. An example is to specify if the message is confirmable. Maybe nanocoap could provide some support with a "message options" struct.
Regarding changes to nanocoap and how gcoap could accommodate them, I guess it depends on the nature of the changes. Actually, at the meeting to today Oleg suggested it is confusing that gcoap-specific functions are named "gcoap_..." and nanocoap functions are named "coap_..." Perhaps one way to buffer future changes is to create "gcoap_" macros for the "coap_" functions to decouple the interfaces.
Ken
[1] https://github.com/t2trg/2017-09-berlin/blob/master/slides/37-RIOT-gcoap-api.pdf [2] https://github.com/kb2ma/RIOT/wiki/gcoap-Features [3] https://github.com/RIOT-OS/RIOT/pull/5598#issuecomment-233753695 [4] https://github.com/kb2ma/RIOT/wiki/Confirmable-Messaging