请教webapi,webservice和纯http通讯的选择优劣

[anabiosispe]

asp.net作服务端，与客户端交互，关于通讯方式上的选择上，有些不太确定的事情，请教一下

先说下我的理解
1.用纯http协议作通讯
客户端通过http的get或者post，发送请求，参数通过queryString或者表单形式发过去。服务端处理完后，发送双方约定的字符串给客户端。
ashx和mvc方法都可以轻松实现。

2.asmx类型的webservice
我认为也只是客户端发送一个http请求过去，然后服务端返回一个响应报文回来。只是限定了发送和响应的文本内容必须是符合soap协议的xml字符串。其他我认为跟普通http请求/响应基本一样。

3.webapi
尚不知道呐，只知道是用json传递数据。但是也是基于http的get和post吧。

看到网上有关于webservice和webapi的选择讨论，我想，在上述3个方式中选择，各自有什么优劣？

webservice被认为劣势的地方主要在于xml字符串承载数据时由于xml节点会多出一些字符来，加大了传输网络的压力吧？
单就服务端响应来说，是否性能会比其他两个要慢一些？在xml节点比较少的情况下，相比webapi来说，也没有什么差距吧？

[娃都会打酱油了]

请先确认你的目标调用方 如果是内部系统，那建议用WS或者WCF，因为主要的传输方面的问题在内部网络百兆甚至千兆面前都不是问题 如果是供第三方调用，简单的话，那可以直接用Handler，但要注意跨域Post问题，但更可能的还是建议用WebAPI，首先它已经封装了很多，而且网上资料虽然有点少，但还是能找到些的，另外这也可以让你更好的了解下Restful规范 另外如果你的客户端是移动端的话，那建议你最好WebAPI了，流量问题是每个移动应用都要注意的问题

[娃都会打酱油了]

再补充下，WS或者WCF用于内网是因为各种序列化和反序列化Frame都帮你做好了

[moonwrite]

我的判断是这样的 封装了下层 那么就会牺牲一点性能 同时会换了一些便利性 用过webapi 如果你是用ajax请求的话，那么返回的json很容易被js使用 不需要反序列化 没有用过webservice

[anabiosispe]

引用 1 楼 starfd 的回复:

请先确认你的目标调用方 如果是内部系统，那建议用WS或者WCF，因为主要的传输方面的问题在内部网络百兆甚至千兆面前都不是问题 如果是供第三方调用，简单的话，那可以直接用Handler，但要注意跨域Post问题，但更可能的还是建议用WebAPI，首先它已经封装了很多，而且网上资料虽然有点少，但还是能找到些的，另外这也可以让你更好的了解下Restful规范 另外如果你的客户端是移动端的话，那建议你最好WebAPI了，流量问题是每个移动应用都要注意的问题

你说用handler就是指直接用http请求的get和post去处理吧，比如ashx和mvc的action方法？

[anabiosispe]

引用 1 楼 starfd 的回复:

请先确认你的目标调用方 如果是内部系统，那建议用WS或者WCF，因为主要的传输方面的问题在内部网络百兆甚至千兆面前都不是问题 如果是供第三方调用，简单的话，那可以直接用Handler，但要注意跨域Post问题，但更可能的还是建议用WebAPI，首先它已经封装了很多，而且网上资料虽然有点少，但还是能找到些的，另外这也可以让你更好的了解下Restful规范 另外如果你的客户端是移动端的话，那建议你最好WebAPI了，流量问题是每个移动应用都要注意的问题

如果直接用http的get和post请求报文的形式传输数据，流量是不是别webapi要更少一些呢？理论上来说，那个更底层，性能也更好一些吧

[shengang1978]

你想得太多了。 使用WebService，WebAPI，在性能上肯定要比直接用http要差。 但是问题是，你的应用真的到了需要这么底层的性能了吗？可以明确的说，99.9999999%的应用不用考虑。 使用API的主要优势的良好的接口封装和App的可维护性。性能在这方面来说是次要的，而且，性能有很多其它方式去提高。纠结于这种协议层的性能是没有必要的，而且走人牛角尖了。

[anabiosispe]

引用 6 楼 shengang1978 的回复:

你想得太多了。 使用WebService，WebAPI，在性能上肯定要比直接用http要差。 但是问题是，你的应用真的到了需要这么底层的性能了吗？可以明确的说，99.9999999%的应用不用考虑。 使用API的主要优势的良好的接口封装和App的可维护性。性能在这方面来说是次要的，而且，性能有很多其它方式去提高。纠结于这种协议层的性能是没有必要的，而且走人牛角尖了。

我也有同感，操作接口少的时候，用httphandler即可通过读取QueryString或者form中的数值进行传递。这是没有任何问题的 但是如果当操作接口内容很多了，再用handler来处理，程序代码就不那么好维护了

[anabiosispe]

引用 2 楼 starfd 的回复:

再补充下，WS或者WCF用于内网是因为各种序列化和反序列化Frame都帮你做好了

这个确实方便，使用wcf承载webservice 话，服务端和客户端都用.net调用，可以直接用代理类传递对象的，省去了数据解析重组的过程。

[anabiosispe]

引用 1 楼 starfd 的回复:

请先确认你的目标调用方 如果是内部系统，那建议用WS或者WCF，因为主要的传输方面的问题在内部网络百兆甚至千兆面前都不是问题 如果是供第三方调用，简单的话，那可以直接用Handler，但要注意跨域Post问题，但更可能的还是建议用WebAPI，首先它已经封装了很多，而且网上资料虽然有点少，但还是能找到些的，另外这也可以让你更好的了解下Restful规范 另外如果你的客户端是移动端的话，那建议你最好WebAPI了，流量问题是每个移动应用都要注意的问题

我有在考虑，intranet应用固然可以方便的使用webservice。internet应用，是不是也可以考虑json-rpc而不是webapi？ 有一些操作，是不能用简单的对资源进行crud来表达的啊

[yanghao198615]

引用 7 楼 txfast 的回复:

[quote=引用 6 楼 shengang1978 的回复:] 你想得太多了。 使用WebService，WebAPI，在性能上肯定要比直接用http要差。 但是问题是，你的应用真的到了需要这么底层的性能了吗？可以明确的说，99.9999999%的应用不用考虑。 使用API的主要优势的良好的接口封装和App的可维护性。性能在这方面来说是次要的，而且，性能有很多其它方式去提高。纠结于这种协议层的性能是没有必要的，而且走人牛角尖了。

我也有同感，操作接口少的时候，用httphandler即可通过读取QueryString或者form中的数值进行传递。这是没有任何问题的 但是如果当操作接口内容很多了，再用handler来处理，程序代码就不那么好维护了[/quote] 那你举例说明下，使用webapi哪些处理这个问题的时候 你哪里又方便了呢？通过httphandler 通过接口+反射自动匹配关键字符，调用对应的实现方法也是很便于扩展的