Web service在物联网IoT中的应用
前言
物联网中应用最广泛的就是request/response通信模式（MQTT采用pub/sub模式）。通信双方一request一response，实际上就是client、server的模式。物联网中host端去request end-device的tempreture，end-device受到request后，responce相应的tempreture。实际上，end-device在此交互中充当着server的角色，为host端提供温度值。
end-device是server？我们想象中的server都是高性能的，每秒钟响应巨量的request，而资源受限的end-device怎么可以是server？但它确实提供了响应request tempreture的服务。
随着移动互联网的发展，client端不仅仅局限于PC，更多地，手机，pad等移动终端设备也应实现对服务器端end-device的访问。因此，end-device需要为不同的开发平台（Java、.net）和操作系统（Linux、Windows）提供服务。那么，有没有什么技术可以实现这种跨越平台，语言，从而达到与end-device(服务器)通信的目的？现在传统意义的服务器端是如何实现这一功能的呢，Web service！
Web Service
什么是Web Service？
形象一点理解的话，Web Service就是一组位于远程服务器上的函数库（或者是存在于网络上的应用程序组件），通过这些函数库（组件），客户端可以通过web访问这些服务器端的service。调用Web service的这一端叫做客户端，而提供Web service的一端叫做服务端。
套用网上一个经典例子：腾讯QQ客户端的天气服务，显然不是腾讯公司发射卫星，自己去维护公司的内部天气服务器，而是去request气象局的服务器（气象局将天气信息通过Web service方式进行公开），再将服务器response回的天气状况进行QQ显示。
Web service的平台技术
从深层次讲，Web Service是一套标准、规范，这套规范了：
- 如何将server端的信息公布出去，让客户端得到足够信息来调用Web service；
- 因为需要跨平台，跨操作系统，所以需要提供一种标准的类型对信息进行封装。
- 规范一种方法，对Web service进行远程访问；
WSDL+XML+HTTP就构成了Web service的三大技术。
- WSDL（Web Services Description Language)：是一种基于xml的语言，是机器可读的。客户端在访问服务器提供的服务的时候，首先要知道，服务器提供的resources的url地址在哪，有哪些服务方法可以调用。WSDL文件就是服务器告诉客户端们我提供了哪些服务方法，他们的调用的url在哪。WSDL保存在Web服务器端，通过固定的url就可以访问到它。
- XML格式：采用XML格式进行消息描述，其优点在于平台无关，它解决了数据的表示问题。
- HTTP协议：Web Service通过HTTP协议发送请求和接收响应。request和response的内容均采用XML格式进行封装，并且在HTTP协议中加上一些首部字段如Content-type用于描述HTTP报文的内容格式。
IoT中的问题
上文提过，物联网中的end-device在交互中充当着server的角色。那么，上述的WSDL+XML+HTTP能否直接套用到end-device中呢？主要有下面几点问题：
- XML文件难以解析，end-device在对文件进行解析时，会消耗过多的CPU和内存资源，XML文件相对来时比较大，在传输过程中会消耗较多的网络资源。
- HTTP封包也比较大，消耗过多网络资源、内存资源。
- HTTP的传输层使用的是TCP协议，在握手挥手过程中，过多的冗余数据Segment。
所以，WSDL+XML+HTTP+TCP是PC级别的，要部署在ROM RAM小到只有几十KB的end-device端中不是很实际，而且还要加上TCP/IP，链路层，外设代码，更显得不堪重负。
因此Web service要应用在物联网中，部署在end-device上必须要需求新的替代品。这就引出了我们的主角——CoAP协议。
IoT中的Web Service
上文提到PC级别的Web Service采用XML+HTTP+TCP的模式，IoT中end-device也采用类似架构的模式，只不过更精简，更易解析，更省资源：JSON+CoAP+UDP。
| PC级别 | end-device |
|---|---|
| XML | JSON |
| HTTP | CoAP |
| TCP | UDP |
XML VS JSON
- JSON相对于XML来讲，数据体积小，JSON传输速度更快；
- XML，JSON都使用结构话方法标记数据，在服务器端和客户端协商好JSON数据结构的情况下，JSON更易编码解码。JSON在JAVAscript主场作战，可以存储Javascript复合对象，有着xml不可比拟的优势。
HTTP VS CoAP
- HTTP报文中过多冗余字段,冗余信息，消耗过多的ROM，RAM，CPU资源，CoAP(Constrained Application Protocol)针对的就是资源（ROM，RAM，CPU）受限的microcontroller,CoAP的报文采用binary encoding，使用更少的bytes,encoding进更多的服务，传达更多的信息，并且其编码解码更为简单；
- CoAP中提供QoS服务，所以其传输层可以采用UDP；进一步缩减其传输的网络资源；
- Observe模式，典型的通信模式就是request/response，一问一答。如果我想要监视一整天的tempreture,需要定时不停地request：喂，温度多少啦？过多的冗余包！Observe功能呢，类似MQTT中的Pub/sub模式，向我的server端订阅一个事件，我要观测observe你。然后，server端就会主动notificate通告你相应的事件。注意哦，这里server端是主动的哦！由此Machine to Machine变得可能；
- HTTP，CoAP都遵循RESTful设计风格，所以这两种格式的报文可以相互转换；
- HTTP同步通信，CoAP异步通信。
TCP VS UDP
- TCP,UDP大家都很熟悉，TCP建立连接需要三次握手，4次挥手，而我仅仅想要的是一个温度值，你给我发这么多冗余的封包？UDP就相当直接，直接将温度值塞进payload字段，直接传送；
- UDP封包小，节省网络资源；
- TCP是repliable的，可靠传输。UDP是unreliable的，结合CoAP的QoS功能，也可以实现可靠的传输。CoAP中，传输的报文会标记它是CON（需要被confirmed的），那么在规定的timeout，没有收到返回的ACK，会再次传送一个相同的报文，同样的遵循指数退避，直到超过最大重传次数。
结论
通过以上分析，JSON+CoAP+UDP的Web service是XML+HTTP+TCP在IoT中的一种替代。基于此架构，可以实现PC，移动终端对end-device端的快速访问。