使用web服務(wù)（web API）已經(jīng)非常普遍，大多應(yīng)用都在使用基于web的REST 架構(gòu)。 Constrained RESTful Environments（CoRE）的工作目標(biāo)是采用恰當(dāng)?shù)姆绞皆谑芟薰?jié)點（如 8位微控制器、較小RAM和ROM）和受限網(wǎng)絡(luò)（例如6LoWPAN，［RFC4944］）上實現(xiàn)REST 架構(gòu)。6LoWPAN等受限網(wǎng)絡(luò)支持把IPv6數(shù)據(jù)包分片成為小的鏈路層數(shù)據(jù)幀。然而，這導(dǎo)致數(shù)據(jù)發(fā)送成功率的下降。CoAP協(xié)議的設(shè)計目標(biāo)之一是使數(shù)據(jù)包開銷盡可能小，以減少分片的發(fā)生。 CoAP目標(biāo)是設(shè)計一個通用的網(wǎng)絡(luò)協(xié)議，滿足受限環(huán)境的特殊需求，特別考慮了能源、樓宇自動化和其它M2M應(yīng)用。CoAP不是對HTTP［RFC2616］協(xié)議的壓縮，而是實現(xiàn)了REST的一個子集，并為M2M應(yīng)用程序做了優(yōu)化。盡管CoAP協(xié)議可以被當(dāng)作一個HTTP壓縮之后變得更緊湊的協(xié)議來使用，但更重要的是它還提供了M2M的一些特性，例如內(nèi)置的資源發(fā)現(xiàn)、多播支持和異步消息交換。本文檔描述了CoAP協(xié)議，它可以很容易的與HTTP協(xié)議互相轉(zhuǎn)換以集成到現(xiàn)有的web中，同時滿足了許多特定的需求，如多播支持、非常小的開銷和足夠簡單以適應(yīng)受限環(huán)境和M2M應(yīng)用。

　　CoAP協(xié)議的交互模型與HTTP的客戶端/服務(wù)端模型類似。然而，在M2M的交互場景中，一個使用CoAP協(xié)議的設(shè)備通常既是客戶端又是服務(wù)端。CoAP中的請求與HTTP協(xié)議中的請求相同，是由客戶端發(fā)起的，請求一個位于服務(wù)端的資源（用URI標(biāo)識），執(zhí)行一個動作（用 Method Code標(biāo)識）。然后服務(wù)端發(fā)回一個響應(yīng)，帶有一個響應(yīng)代碼（Response Code），這個響應(yīng)中有可能也包含一個資源的表現(xiàn)（附帶響應(yīng)格式）。與HTTP協(xié)議不同的是，CoAP的交互是異步的，構(gòu)建于面向數(shù)據(jù)報的傳輸協(xié)議，如UDP。交互是通過一個消息層來實現(xiàn)的，消息層提供了可選的可靠性支持（采用指數(shù)回退）。CoAP協(xié)議中定義了四種類型的消息： CON， NON， ACK和RST。這四種類型的消息中包含有請求和響應(yīng)標(biāo)識碼，標(biāo)識著這些消息是請求還是響應(yīng)。請求可以包含在CON和NON兩種類型中，而響應(yīng)則除了可以包含在CON和NON之中，還可以包含在附帶響應(yīng)的ACK中。從邏輯上，可以把CoAP協(xié)議劃分為兩層：消息層，用于處理UDP數(shù)據(jù)包和異步；請求/響應(yīng)層，使用Method和Response Code，具體見圖1。當(dāng)然，CoAP是一個協(xié)議，消息和請求/響應(yīng)僅僅是其頭部特性。
?