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

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