with sensors scattered around the home, which are turned into internet devices via the proxy of a home gateway. Energy Visible2 is a RESTful 6LoWPAN based application framework for smart homes addressing service discovery and service description. A syndication mechanism using RESTful messaging system is also specified. Nimbits3 is a free, social and open source Internet of Things based data historian server built on cloud computing architecture providing connectivity between devices using data points. Environmental sensor nodes, energy monitoring systems and RFID-tagged objects are connected to the web using Sun Spots, PLOGGS which is demonstrated in .A data platform as a middleware between the physical world and the virtual digital world focusing on vehicular networks and environmental perception is designed in . Information collected from infrastructures beside the roads is processed and helpful advices are provided to the interested users. We see that most of the application development for wireless sensor network uses REST over HTTP which is not suitable for resource constrained devices. Low power consumption is observed in Wireless Sensor Network running on CoAP server when compared to that running on HTTP server . This makes CoAP a better choice for use in Wireless Sensor Network. We propose a design that could be employed for the Web of Things applications development, which uses a more efficient REST-based protocol called as CoAP. Considering the realm of sensing through the use of Radio Frequency Identification (RFID), which uses tag based identification that uses radio-frequency electromagnetic radiation for transmission of information, it is proved to be unreliable owing to the small range and inability to transmit across obstructions. The privacy offered by RFID is questionable and it can be easily blocked through the use of a Faraday Cage to block electromagnetic transmissions. Metals like thin foils can cause interference with RFID detection . RFID poses a setback in transmission range of messages to approximately 8~30 m; hence the syndication mechanism that we aim to establish through the use of CoAP messaging across long distances cannot be fulfilled. Frequent traffic updates to the subscribed users of the system can be realized through the use of WSN. Reasoning as to why Zigbee is a better standard to be used for Wireless Sensor Network in comparison to Bluetooth technology is, we find that it offers high flexibility in the network by allowing the use of clusters, tree and mesh networks. Furthermore, Zigbee allows roughly more than 65,000 nodes in a WSN according to its specification. Another boon is its transmission range varying from 1-100 m in contrast to Bluetooth which offers only 1-10 m .Zigbee offers better power management options and a longer battery life, essential for low-power small devices that may be located in remote regions and are not frequently maintained . IV.COAPAND6LOWPAN In constrained machine-to-machine applications we find that the devices usually have 8-bit microcontrollers with limited RAM and ROM. Using networks like 6LoWPAN  we can aim to minimize the message overhead by reducing fragmentation of IPv6 packets. CoAP  serves to be an alternative to HTTP, but at the same time provides an effective mapping mechanism that allows proxies to be built providing access to CoAP resources through HTTP or vice versa. The significant changes from HTTP to CoAP highlighted would be the use of UDP (User Datagram Protocol) asynchronously for the emulation of the request-response model. The lack of complete reliability as in TCP is compensated by the feature of exponential back-off ensuring optional reliability. Multicast requests in CoAP are not directed to the CoAP endpoint instead are addressed to an IP multicast address. CoAP stack as shown in Fig.1 is visualized to be into 2 layers logically, the messaging and the request/response layer. CoAP requests are sent over the network to access the URI of the resource in the server. Proxying and caching benefits of CoAP helps in speedy processing of requests and response messages. CoAP also uses security binding to the Datagram Transport Layer Security (DTLS).
Confirmable (CON), Acknowledgement (ACK), Reset (RST) and Non-Confirmable (NON) are the four types of messages that are defined in the protocol as explained below: 1)CON: Confirmable message requires an Acknowledgement message (ACK) from the recipient for a successful transmission carrying the corresponding Message ID. 2)NON: Non-Confirmable message does not require an Acknowledgement Message (ACK). 3)ACK: Acknowledges that a specific Confirmable message has arrived. 4)RST: Indicates that a specific message be it Confirmable or Non-Confirmable was received nevertheless the processing was hindered due to context mismatch. 2