Expand description
The coap-handler-implementations crate provides a few convenience, example or
reference implementations of the coap-handler interface.
They range 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 TypeHandler enables the easy creation of
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.
§History
This code used to be part of coap-handler, but while the interface needs to stabilize fast (as incompatible changes there propagate to implementations), the implementations still need to develop fast (but it doesn’t hurt too much if one code part is using the old SimpleRenderable while another uses a newer NeverFound).
Version 0.1 is what was available in coap-handler (if Cargo allowed cyclic dependencies,
coap-handler would pub use this crate); users are encouraged to just use
coap-handler-implementations directly.
§Options Hiding
A common mechanism in handlers is that handlers “consume” options. For example, the ForkingHandler built through HandlerBuilder::at “eats” the Uri-Path; likewise, an Accept-based dispatcher would consume the Accept option.
This allows the handlers themselves to check for any left-over critical options and fail if they can’t handle them – without the need to mask them out there assuming (without an actual check) that prior wrappers took care of them.
§Feature flags
leaky_names— Make a few items pub available that do not have stability guarantees. While this is useful in the context of building handlers into statics, apply the same caution as with any other crate feature that’s disabling stability guarantees: Don’t use this from libraries, for your dependents will run the risk of accidentally using unstable names.
Modules§
Structs§
- Empty
- A type that (for minicbor typed handlers) represents an empty payload.
- Forking
Handler - Forking
Tree Handler - Never
Found - A resource that unconditionally responds 4.04 Not Found.
- Simple
Renderable Data - Information a SimpleRenderable needs to carry from request to response.
- Simple
Rendered - A container that turns any SimpleRenderable (including &str) into a CoAP resource Handler.
- Type
Handler - Wrapper for resource handlers that are implemented in terms of GETting, POSTing or PUTting objects in CBOR format.
- Type
Request Data - Data carried around between a request and its response for TypeHandlers
- Typed
Static Renderable - Well
Known Core leaky_names - Wrapper around a reporting handler that makes all reported resources discoverable at the path
/.well-known/core.
Enums§
- Forking
Request Data - Tagged-union container for ForkingHandler
Traits§
- Delete
Renderable - Subset of
TypeRenderablethat handles the DELETE method. - Fetch
Renderable - Subset of
TypeRenderablethat handles the FETCH method. - GetRenderable
- Subset of
TypeRenderablethat handles the GET method. - Handler
Builder - Trait implemented by default on all handlers that lets the user stack them using a builder-like syntax.
- IPatch
Renderable - Subset of
TypeRenderablethat handles the IPATCH method. - Post
Renderable - Subset of
TypeRenderablethat handles the POST method. - PutRenderable
- Subset of
TypeRenderablethat handles the PUT method. - Reporting
Handler Builder - Extension trait for handlers that also implement Reporting.
- Simple
Renderable - A simplified Handler trait that can react to GET requests and will render to a fmt::Write object with blockwise backing.
- Type
Renderable - A Handler trait that supports various CoAP methods on a data structure that can be serialized, eg. in CBOR.
Functions§
- new_
dispatcher - with_
delete - with_
delete_ fetch - with_
delete_ fetch_ ipatch - with_
delete_ ipatch - with_
fetch - with_
fetch_ ipatch - with_
get - with_
get_ delete - with_
get_ delete_ fetch - with_
get_ delete_ fetch_ ipatch - with_
get_ delete_ ipatch - with_
get_ fetch - with_
get_ fetch_ ipatch - with_
get_ ipatch - with_
get_ post - with_
get_ post_ delete - with_
get_ post_ delete_ fetch - with_
get_ post_ delete_ fetch_ ipatch - with_
get_ post_ delete_ ipatch - with_
get_ post_ fetch - with_
get_ post_ fetch_ ipatch - with_
get_ post_ ipatch - with_
get_ post_ put - with_
get_ post_ put_ delete - with_
get_ post_ put_ delete_ fetch - with_
get_ post_ put_ delete_ ipatch - with_
get_ post_ put_ fetch - with_
get_ post_ put_ fetch_ ipatch - with_
get_ post_ put_ ipatch - with_
get_ put - with_
get_ put_ delete - with_
get_ put_ delete_ fetch - with_
get_ put_ delete_ fetch_ ipatch - with_
get_ put_ delete_ ipatch - with_
get_ put_ fetch - with_
get_ put_ fetch_ ipatch - with_
get_ put_ ipatch - with_
ipatch - with_
post - with_
post_ delete - with_
post_ delete_ fetch - with_
post_ delete_ fetch_ ipatch - with_
post_ delete_ ipatch - with_
post_ fetch - with_
post_ fetch_ ipatch - with_
post_ ipatch - with_
post_ put - with_
post_ put_ delete - with_
post_ put_ delete_ fetch - with_
post_ put_ delete_ fetch_ ipatch - with_
post_ put_ delete_ ipatch - with_
post_ put_ fetch - with_
post_ put_ fetch_ ipatch - with_
post_ put_ ipatch - with_
put - with_
put_ delete - with_
put_ delete_ fetch - with_
put_ delete_ fetch_ ipatch - with_
put_ delete_ ipatch - with_
put_ fetch - with_
put_ fetch_ ipatch - with_
put_ ipatch