The coap-handler crate defines an interface between a [CoAP] server (that listens for
requests on the network and parses the messages) and request handlers (that process the
requests and creates responses from them).
The interface is generic over message formats by using the [coap-message] crate, which allows the handler to construct the response right into the send buffer prepared by the server implementation. By separating the request processing and the response phase, a server can be implemented even on network stacks that have only a single network buffer.
Along with the interface, the crate provides some simple implementations, from the generic "4.04
Not Found" responder up to a handler that creates a [write] formatter for GET-only resources,
and even provides [block-wise transfer] that.
The [implementations::SimpleCBORWrapper] enables the easy creation of [serde_cbor] based
resource implementations with GET, PUT and POST support in CBOR format.
The HandlerBuilder implements crude static path based routing
that may suffice for some applications, and is also useful to get started quickly.
Known shortcomings of the current interface are:
Handler mutability is a bit iffy -- there's no way yet for the server to express any promise
about only running one handler at a time, thus handlers often hold shared references to a
[RefCell] that is [borrow_mut()]'d (if no other code that can be concurrent with the CoAP
server can have access to the T), or [try_borrow_mut()]'d (and errs back with a 5.03
Max-Age:0 response).
Alternatives (where multiple handlers could be built based on a single mutable reference to their data) are being explored.
HandlerBuilder uses [core::iter::Iterator::cmp_by] which is still behind the
iter_order_by feature, making the crate nightly-only. If this becomes an issue for users
before the feature gets stabilized, it should be possible to replace that with a custom
implementation.License: LGPL-3.0