1、定义：常规的WEB API就是指使用HTTP协议通过网络调用的API；

      其实就是一个WEB系统，对外提供给别人调用的API，这种调用通常是程序的方式，而不是简简单单的浏览器中输入URL访问。

      像我们常规使用的WEB Service、c#的一般处理程序、WCF都属于WEB API、以及Java中的响应Ajax的Servlet都算是web api

 

2、使用原生HTTP协议的好处？

HTTP协议的好处就是规模大而且全世界认可，毕竟大家都用了这么多年了，你公开的web api如果严格遵守HTTP规范的话，那么全世界的设备或程序都可以遵照http的标准方式访问你的api，调用更加简洁一致；而HTTP协议内部的URL直接指向一个资源，协议的Method分别有GET（获取）、POST（添加）、DELETE（删除）、PUT（更新）等操作；

 

假如不严格遵守HTTP的resutful风格也不是说什么都干不了；例如一个项目全部是自己公司一个团队开发的，对资源的增删改查操作清一色地使用AJAX的GET/POST方式结合json封装各种crud的请求参数包的方式，而根本不用HTTP原生的POST、DELETE、PUT、GET方法，我们可以叫这种风格为 “一盖（GET）到底或一炮（POST）到底”，本来这样开发封装参数包的方式也是非常灵活的，事实上很多系统都是这么干的；如果全是自己公司内部团队或小范围的几个熟悉的团队研发，这种一炮到底的风格并没有什么问题，而且还非常灵活；

 

但是你要公布WEB API给世界上千千万万的第三方使用的时候，尤其这些第三方用的什么技术和什么硬件事先你都不知道（比如一家大的电商网站想往外公布一些webapi获取它的产品信息，这个时候他是不知道将来会有谁来调用这些webapi的，更不知道未来调用方使用的技术等），将来调用的第三方更可不可能知道你公布的奇怪的参数包的格式，即使你给了说明文档或者调用的代码示例，人家解析起来应该也很费力（至少要多加几行解析你个性化参数包的代码），而不是像大家都严格遵守的标准HTTP协议那样解析起来很便捷，例如很多硬件设备自带的能解析Http的程序能解析标准协议但是不能保证人家能解析我们个性化的参数包，即使能解析也得多加不少代码，而不像解析原始请求那么简单；

 

3、RESTFUL架构风格？

既然知道了严格遵守HTTP协议的好处后，那么继续说下RESTFUL，RESTFUL架构风格网上介绍的很多，比如asp.net webapi学起来也挺简单，毕竟vs都有示例代码，比较郁闷的是一开始学习这东西时虽然知道这样做但是并没有明白为啥要这样做（我用ajax结合ashx或jsonresult的方式也能工作啊）；

 

REST（Representational State Transfer，简称REST），HTTP是一个协议，协议内部包含URI、请求类型、消息长度、希望返回数据的类型以及消息体等信息，而这其中的URI叫统一资源定位符，说白了是针对资源的，而对资源操作无非就是增删改查，这些操作都是在服务器端的，而返回给请求的客户端的数据无论是json还是xml都是一种需要展示的信息或操作的结果而已，其实HTTP来回无非在传达client给server的命令和server给client的请求结果去显示而已；对于常规的增删改查Http早已经自带了POST/Delete/Put/Get等操作，当然还有head等等，如果我们严格遵守了这些面向资源的URI，然后剩下的操作通过http的命令来处理的话，那么就已经能轻松的做到将展示状态在服务器端和客户端之间来回传输，虽然“一炮到底”的风格也啥都能做，但是解析起来肯定没有原生HTTP规则来的通用，因此将能更好支持REST的架构称之为RESTFUL架构（是更好地支持，因为一炮到底的架构也不是支持，只是不够优雅不按照通用标准玩而已），当然RESTFUL架构除了这些还有很多别的规则需要我们遵守(例如url要清晰名了一看就知道是什么资源)。尤其是公布对外的api的时候，严格准守restful风格会让使用你的api让人用起来得心应手。

 

4、而asp.net web api天生就是根据restful风格来的，所以说你会asp.net web api编程那你多少肯定已经知道rest和restful是怎么回事了，毕竟每个url直接都对应到具体的资源上了，对资源的增删改查都默认走HTTP的POST、DELETE、 PUT、 GET方式而不是自己在参数包中指定了。

 

5、什么时候该用RESTFUL 风格的web api?

肯定是给第三方提供编程接口的时候用了（尤其是调用的第三方还不知道是谁呢的时候），但是在选择协议和风格的时候肯定是用http和restful风格更好些，在提供面向资源的接口时web api的restful风格绝对是很不错的选择，uri本身就是资源定位的，而http还自带增删改查的命令字，这样写出来的api接口全世界都好理解，例如获取产品信息的接口，产品就是资源、获取人员信息的接口人员就是资源，说白了URI是按照资源来切分的;如果是自己内部团队搞的soa架构或者是已知的能相互沟通的团队那用传统的清一色的post或get也没啥问题，毕竟这样灵活，大伙这么多年都用惯了；

 

6、为什么要使用微服务？

webapi除了公布资源之外还可能是一个复杂的算法而不是一个数据资源，例如一个业务算法、数据算法等，这时候就不适合使用面向资源的概念，虽然也能用web api来实现，但是思路应该从数据资源转向抽象的功能、业务算法等，为了达到松耦合的目的，资源和资源是相互分开单独处理的，而业务功能服务也是同样道理，总不能一个服务修改了或升级了导致原来别的服务受影响、或者使现有的调用方不好用了，所以要将不同的服务功能也细化后拆开达到一个微服务的形式，这样以后一个服务发生变化以后别的服务照常运行（舱体隔离的原理：据说郑和下西洋的船就用了这个智慧，一个船舱漏了船不至于沉到海里），而不是逼着客服去升级程序，因为客户可能并不需要你这个变化的服务或者人家压根就没有调用过你修改的这个服务，在代码层面也不涉及到编译问题或者引用不到的问题，这就是微服务的好处，当然如果从广义上讲服务也可理解为资源的话，那么微服务和restful确实是有交集的，但是从对资源增删改查的操作来说微服务和面向的资源还是有些差别，RESTFUL风格是面向资源的，而微服务是按照最小业务切分的，每个最小业务中是会包含一到多个资源的。

 

7、将restful风格的web api和微服务落地策略？

像web api无论是用什么技术实现，只要保证你提供出去的接口是面向一个资源的，而且利用http的get、post、put、delete来实现你的增删改查，还能根据调用方的需要返回不同格式的数据（入json/xml），那么你就已经实现restful风格了，也比较完美的实现了一个web api了，实现之后直接将引用web api的方法或简短的代码公布出去就ok了。

 

而微服务落地则需要对业务非常熟悉，将业务的各个小细节操作进行拆分，拆分的粒度就是一个业务变化了不会影响另一个业务，一个服务就干一个业务而不是一大坨好几个业务功能耦合在一个服务接口里了，如果耦合在一起那么就会导致一个业务变了别的都跟着受影响，具体操作反应到代码上就是提供原子方法（可以是一个rest资源或只做一件事的一个方法），在原子方法的基础上提供业务原子服务，在架构上为服务或处理服务的代码插件化，当然微服务就是SOA中的一个划分风格，准确说是把舱体隔离风格或蜂巢结构的风格应用到服务上了。

 

从为客户端服务的层面来说，微服务是包含restful中资源这部分的；