Revisiting the current CoapCode implementation, I got the impression that the APIs for creating new requests and responses could be improved to leave less room for potential errors by introducing separate enums for request methods as well as response and signaling codes. This PR implements this change, creating a RequestMethod, a ResponseCode, and a SignalingCode enum in the process, while turning the CoapCode enum into an immutable class that carries the numeric values.
Due to the fact that the empty messages sent during the CoAP ping are currently handled as requests, I could not remove the empty value from the RequestMethod enum. I added a TODO that this value should be revisited during future reworks of the internal API. However, maybe it could also be left as is.
Since this is unfortunately another breaking API change, we could keep this PR on hold for a while until a 7.0.0 release is due.
Revisiting the current CoapCode implementation, I got the impression that the APIs for creating new requests and responses could be improved to leave less room for potential errors by introducing separate enums for request methods as well as response and signaling codes. This PR implements this change, creating a
RequestMethod, aResponseCode, and aSignalingCodeenum in the process, while turning theCoapCodeenum into an immutable class that carries the numeric values.Due to the fact that the empty messages sent during the CoAP ping are currently handled as requests, I could not remove the
emptyvalue from theRequestMethodenum. I added a TODO that this value should be revisited during future reworks of the internal API. However, maybe it could also be left as is.Since this is unfortunately another breaking API change, we could keep this PR on hold for a while until a 7.0.0 release is due.