Struct toad_msg::code::Code

pub struct Code {
    pub class: u8,
    pub detail: u8,
}

CoAP Code Registries

generated from RFC7252 section 12.1

This document defines two sub-registries for the values of the Code field in the CoAP header within the “Constrained RESTful Environments (CoRE) Parameters” registry, hereafter referred to as the “CoRE Parameters” registry.

Values in the two sub-registries are eight-bit values notated as three decimal digits c.dd separated by a period between the first and the second digit; the first digit c is between 0 and 7 and denotes the code class; the second and third digits dd denote a decimal number between 00 and 31 for the detail.

All Code values are assigned by sub-registries according to the following ranges:

0.00      Indicates an Empty message (see Section 4.1).

0.01-0.31 Indicates a request.  Values in this range are assigned by
          the "CoAP Method Codes" sub-registry (see Section 12.1.1).

1.00-1.31 Reserved

2.00-5.31 Indicates a response.  Values in this range are assigned by
          the "CoAP Response Codes" sub-registry (see
          Section 12.1.2).

6.00-7.31 Reserved

RFC7252 Section 12.1.1 Method Codes

## Method Codes [_generated from RFC7252 section 12.1.1_](https://datatracker.ietf.org/doc/html/rfc7252#section-12.1.1)

The name of the sub-registry is “CoAP Method Codes”.

Each entry in the sub-registry must include the Method Code in the range 0.01-0.31, the name of the method, and a reference to the method’s documentation.

Initial entries in this sub-registry are as follows:

                    +------+--------+-----------+
                    | Code | Name   | Reference |
                    +------+--------+-----------+
                    | 0.01 | GET    | [RFC7252] |
                    | 0.02 | POST   | [RFC7252] |
                    | 0.03 | PUT    | [RFC7252] |
                    | 0.04 | DELETE | [RFC7252] |
                    +------+--------+-----------+

                     Table 5: CoAP Method Codes

All other Method Codes are Unassigned.

The IANA policy for future additions to this sub-registry is “IETF Review or IESG Approval” as described in [RFC5226].

The documentation of a Method Code should specify the semantics of a request with that code, including the following properties:

o The Response Codes the method returns in the success case.

o Whether the method is idempotent, safe, or both.

RFC7252 Section 12.1.2 Response Codes

## Response Codes [_generated from RFC7252 section 12.1.2_](https://datatracker.ietf.org/doc/html/rfc7252#section-12.1.2)

The name of the sub-registry is “CoAP Response Codes”.

Each entry in the sub-registry must include the Response Code in the range 2.00-5.31, a description of the Response Code, and a reference to the Response Code’s documentation.

Initial entries in this sub-registry are as follows:

         +------+------------------------------+-----------+
         | Code | Description                  | Reference |
         +------+------------------------------+-----------+
         | 2.01 | Created                      | [RFC7252] |
         | 2.02 | Deleted                      | [RFC7252] |
         | 2.03 | Valid                        | [RFC7252] |
         | 2.04 | Changed                      | [RFC7252] |
         | 2.05 | Content                      | [RFC7252] |
         | 4.00 | Bad Request                  | [RFC7252] |
         | 4.01 | Unauthorized                 | [RFC7252] |
         | 4.02 | Bad Option                   | [RFC7252] |
         | 4.03 | Forbidden                    | [RFC7252] |
         | 4.04 | Not Found                    | [RFC7252] |
         | 4.05 | Method Not Allowed           | [RFC7252] |
         | 4.06 | Not Acceptable               | [RFC7252] |
         | 4.12 | Precondition Failed          | [RFC7252] |
         | 4.13 | Request Entity Too Large     | [RFC7252] |
         | 4.15 | Unsupported Content-Format   | [RFC7252] |
         | 5.00 | Internal Server Error        | [RFC7252] |
         | 5.01 | Not Implemented              | [RFC7252] |
         | 5.02 | Bad Gateway                  | [RFC7252] |
         | 5.03 | Service Unavailable          | [RFC7252] |
         | 5.04 | Gateway Timeout              | [RFC7252] |
         | 5.05 | Proxying Not Supported       | [RFC7252] |
         +------+------------------------------+-----------+

                    Table 6: CoAP Response Codes

The Response Codes 3.00-3.31 are Reserved for future use. All other Response Codes are Unassigned.

The IANA policy for future additions to this sub-registry is “IETF Review or IESG Approval” as described in [RFC5226].

The documentation of a Response Code should specify the semantics of a response with that code, including the following properties:

o The methods the Response Code applies to.

o Whether payload is required, optional, or not allowed.

o The semantics of the payload. For example, the payload of a 2.05 (Content) response is a representation of the target resource; the payload in an error response is a human-readable diagnostic payload.

o The format of the payload. For example, the format in a 2.05 (Content) response is indicated by the Content-Format Option; the format of the payload in an error response is always Net-Unicode text.

o Whether the response is cacheable according to the freshness model.

o Whether the response is validatable according to the validation model.

o Whether the response causes a cache to mark responses stored for the request URI as not fresh.

Examples

use toad_msg::Code;

assert_eq!(Code { class: 2,
                  detail: 5 }.to_string(),
           "2.05".to_string());

Fields

class: u8

The “class” of message codes identify it as a request or response, and provides the class of response status:

class	meaning
0	Message is a request
2	Message is a success response
4	Message is a client error response
5	Message is a server error response

detail: u8

2-digit integer (range [0, 32)) that provides granular information about the response status.

Will always be 0 for requests.

Implementations

impl Code

pub const fn new(class: u8, detail: u8) -> Self

Create a new Code

use toad_msg::Code;

let content = Code::new(2, 05);

pub fn to_human(&self) -> [char; 4]

Get the human string representation of a message code

Returns

A char array

This is to avoid unnecessary heap allocation, you can create a String with FromIterator::<String>::from_iter, or if the alloc feature of toad is enabled there is a ToString implementation provided for Code.

use toad_msg::Code;

let code = Code { class: 2,
                  detail: 5 };
let chars = code.to_human();
let string = String::from_iter(chars);
assert_eq!(string, "2.05".to_string());

pub fn kind(&self) -> CodeKind

Get whether this code is for a request, response, or empty message

use toad_msg::{Code, CodeKind};

let empty: Code = Code::new(0, 0);
assert_eq!(empty.kind(), CodeKind::Empty);

let req = Code::new(0, 1); // GET
assert_eq!(req.kind(), CodeKind::Request);

let resp = Code::new(2, 5); // OK CONTENT
assert_eq!(resp.kind(), CodeKind::Response);

pub const EMPTY: Self = _

Messages and Endpoints

generated from RFC7252 section 4.1

A CoAP endpoint is the source or destination of a CoAP message. The specific definition of an endpoint depends on the transport being used for CoAP. For the transports defined in this specification, the endpoint is identified depending on the security mode used (see Section 9): With no security, the endpoint is solely identified by an IP address and a UDP port number. With other security modes, the endpoint is identified as defined by the security mode.

There are different types of messages. The type of a message is specified by the Type field of the CoAP Header.

Separate from the message type, a message may carry a request, a response, or be Empty. This is signaled by the Request/Response Code field in the CoAP Header and is relevant to the request/response model. Possible values for the field are maintained in the CoAP Code Registries (Section 12.1).

An Empty message has the Code field set to 0.00. The Token Length field MUST be set to 0 and bytes of data MUST NOT be present after the Message ID field. If there are any bytes, they MUST be processed as a message format error.

pub const GET: Self = _

GET

generated from RFC7252 section 5.8.1

The GET method retrieves a representation for the information that currently corresponds to the resource identified by the request URI. If the request includes an Accept Option, that indicates the preferred content-format of a response. If the request includes an ETag Option, the GET method requests that ETag be validated and that the representation be transferred only if validation failed. Upon success, a 2.05 (Content) or 2.03 (Valid) Response Code SHOULD be present in the response.

The GET method is safe and idempotent.

pub const POST: Self = _

POST

generated from RFC7252 section 5.8.2

The POST method requests that the representation enclosed in the request be processed. The actual function performed by the POST method is determined by the origin server and dependent on the target resource. It usually results in a new resource being created or the target resource being updated.

If a resource has been created on the server, the response returned by the server SHOULD have a 2.01 (Created) Response Code and SHOULD include the URI of the new resource in a sequence of one or more Location-Path and/or Location-Query Options (Section 5.10.7). If the POST succeeds but does not result in a new resource being created on the server, the response SHOULD have a 2.04 (Changed) Response Code. If the POST succeeds and results in the target resource being deleted, the response SHOULD have a 2.02 (Deleted) Response Code. POST is neither safe nor idempotent.

pub const PUT: Self = _

PUT

generated from RFC7252 section 5.8.3

The PUT method requests that the resource identified by the request URI be updated or created with the enclosed representation. The representation format is specified by the media type and content coding given in the Content-Format Option, if provided.

If a resource exists at the request URI, the enclosed representation SHOULD be considered a modified version of that resource, and a 2.04 (Changed) Response Code SHOULD be returned. If no resource exists, then the server MAY create a new resource with that URI, resulting in a 2.01 (Created) Response Code. If the resource could not be created or modified, then an appropriate error Response Code SHOULD be sent.

Further restrictions to a PUT can be made by including the If-Match (see Section 5.10.8.1) or If-None-Match (see Section 5.10.8.2) options in the request.

PUT is not safe but is idempotent.

pub const DELETE: Self = _

DELETE

generated from RFC7252 section 5.8.4

The DELETE method requests that the resource identified by the request URI be deleted. A 2.02 (Deleted) Response Code SHOULD be used on success or in case the resource did not exist before the request.

DELETE is not safe but is idempotent.

Trait Implementations

impl Clone for Code

fn clone(&self) -> Code

Returns a copy of the value.

fn clone_from(&mut self, source: &Self)

Performs copy-assignment from source.

impl Debug for Code

fn fmt(&self, f: &mut Formatter<'_>) -> Result

Formats the value using the given formatter.

impl From<Code> for u8

fn from(code: Code) -> u8

Converts to this type from the input type.

impl From<u8> for Code

fn from(b: u8) -> Self

Converts to this type from the input type.

impl Hash for Code

fn hash<__H: Hasher>(&self, state: &mut __H)

Feeds this value into the given Hasher.

fn hash_slice<H>(data: &[Self], state: &mut H)where H: Hasher, Self: Sized,

Feeds a slice of this type into the given Hasher.

impl Ord for Code

fn cmp(&self, other: &Code) -> Ordering

This method returns an Ordering between self and other.

fn max(self, other: Self) -> Selfwhere Self: Sized,

Compares and returns the maximum of two values.

fn min(self, other: Self) -> Selfwhere Self: Sized,

Compares and returns the minimum of two values.

fn clamp(self, min: Self, max: Self) -> Selfwhere Self: Sized + PartialOrd<Self>,

Restrict a value to a certain interval.

impl PartialEq<Code> for Code

fn eq(&self, other: &Code) -> bool

This method tests for self and other values to be equal, and is used by ==.

fn ne(&self, other: &Rhs) -> bool

This method tests for !=. The default implementation is almost always sufficient, and should not be overridden without very good reason.

impl PartialOrd<Code> for Code

fn partial_cmp(&self, other: &Code) -> Option<Ordering>

This method returns an ordering between self and other values if one exists.

fn lt(&self, other: &Rhs) -> bool

This method tests less than (for self and other) and is used by the < operator.

fn le(&self, other: &Rhs) -> bool

This method tests less than or equal to (for self and other) and is used by the <= operator.

fn gt(&self, other: &Rhs) -> bool

This method tests greater than (for self and other) and is used by the > operator.

fn ge(&self, other: &Rhs) -> bool

This method tests greater than or equal to (for self and other) and is used by the >= operator.

impl ToString for Code

fn to_string(&self) -> String

Converts the given value to a String.

impl Copy for Code

impl Eq for Code

impl StructuralEq for Code

impl StructuralPartialEq for Code