2.2 请求响应模型

CoAP的请求和响应的语义都包含在CoAP消息中，请求和响应的消息分别带有方法码（Method Code）和响应码（Response Code）。可选的或者是默认的请求和响应信息，例如URI和数据的媒体类型等，都做为协议中的选项部分。CoAP使用一个Token来匹配请求对应的响应（见5.3节）。注意，这个Token和消息ID不同。

请求消息分为CON和NON两种。对于CON类型的请求，如果响应数据可以立即生成，那么对于请求消息的ACK就会同时携带响应数据。这就是附带响应，在5.2.1节中详细讲述。（不需要对附带响应再进行单独的应答，因为假如携带响应数据的ACK丢失，那么客户端会重传请求消息）。图4中展示了对于两个GET请求，服务端返回附带响应的例子，一个成功，一个导致了4.04（资源未找到）响应。

    Client              Server       Client              Server
       |                  |             |                  |
       |   CON [0xbc90]   |             |   CON [0xbc91]   |
       | GET /temperature |             | GET /temperature |
       |   (Token 0x71)   |             |   (Token 0x72)   |
       +----------------->|             +----------------->|
       |                  |             |                  |
       |   ACK [0xbc90]   |             |   ACK [0xbc91]   |
       |   2.05 Content   |             |  4.04 Not Found  |
       |   (Token 0x71)   |             |   (Token 0x72)   |
       |     "22.5 C"     |             |   "Not found"    |
       |<-----------------+             |<-----------------+
       |                  |             |                  |

               图4 对两个GET请求的附带响应

如果请求消息是一个CON类型的，而服务端无法立即响应，那么它就会立即发回一个空的ACK消息，以免客户端重传请求消息。当响应数据准备好了之后，服务器端就会把它组装成一个新的CON类型的消息（这需要客户端的ACK）。这种形式被称为“单独响应”，如图5所示，更多细节参见5.2.2节。

                    Client              Server
                       |                  |
                       |   CON [0x7a10]   |
                       | GET /temperature |
                       |   (Token 0x73)   |
                       +----------------->|
                       |                  |
                       |   ACK [0x7a10]   |
                       |<-----------------+
                       |                  |
                       ... Time Passes  ...
                       |                  |
                       |   CON [0x23bb]   |
                       |   2.05 Content   |
                       |   (Token 0x73)   |
                       |     "22.5 C"     |
                       |<-----------------+
                       |                  |
                       |   ACK [0x23bb]   |
                       +----------------->|
                       |                  |

                    图5 GET请求和独立响应

如果一个请求是以NON类型的消息发送的，那么一般来说响应也将是一个NON类型的消息，但服务器也有可能发送一个CON类型的消息作为响应。这种交互如图6所示。

                     Client              Server
                       |                  |
                       |   NON [0x7a11]   |
                       | GET /temperature |
                       |   (Token 0x74)   |
                       +----------------->|
                       |                  |
                       |   NON [0x23bc]   |
                       |   2.05 Content   |
                       |   (Token 0x74)   |
                       |     "22.5 C"     |
                       |<-----------------+
                       |                  |

               图6 NON类型消息的请求和响应

类似HTTP，CoAP协议也使用GET, PUT, POST和DELETE方法，具体的语义在5.8节中讲述。（注意，CoAP协议的这些方法的语义很像HTTP，但和HTTP不完全一样。读者对于HTTP协议的经验对理解CoAP是很有帮助的，但是二者之间还是有不少的区别，值得阅读本规范）。

在特定的情况下，可以增加这四种方法之外的方法。新的方法不一定要使用成对的请求/响应的形式。即使对于现有的方法，一个请求也有可能产生多个响应，例如一个多播请求（第8章），或者一个订阅(Observe)选项。

服务端对于URI的支持是很简单的，因为客户端已经把URI拆分为主机、端口、路径和参数，并可以使用默认值。响应代码是HTTP状态代码的一个子集，但增加了几个CoAP特有的响应码，在5.9节中讲述。