7.10 Web Service开发中需要注意的问题（1）

7.10  Web Service开发中需要注意的问题（1）

1．接口是自说明的

接口的名字、参数和返回值应该一看就知道这接口大概是干什么用的。当然接口描述文档肯定是必需的，但这些描述文档的质量谁知道怎么样呢，谁有空天天翻着文档写东西呢，又有谁会背下来呢？所以让人眼前一亮的接口命名绝对值得，这也是所有代码书会告诉你应该遵守的一条规则。

2．服务接口粒度要合适

Web Service服务接口粒度太小了，那纯粹是不考虑XML解析性能了。一般新手容易犯这毛病，简单地把类的方法暴露出来做服务接口，这样其实是把原来在 local的调用放到了remote，除此之外几乎没有任何好处。粒度太大，会给使用者带来很多麻烦，因为在Web Service中，粒度很大的服务一般都需要很多参数来映射该服务各种各样的情况。

3．接口参数要尽量简单

只有一个参数的服务接口，往往不能满足业务需求。但过多的参数也提高了出错的几率，增加了测试的成本。所以，参数恰到好处为妙。

4．要提供对接口参数和返回值的校验

严格来说，对接口参数和返回值的验证也应该算是Web Service接口声明的一部分。增加对参数和返回值的校验，有利于减少调用者的疑惑，系统接受什么样的参数，返回值是什么格式都一目了然。但是这需要一个很好的权衡，否则调用者会觉得你暴露的方法很难用，因为限制太多了。比较理想的系统应该是宽进严出的，目标用户越多越应该注意这一点。要在宽进严出和全面校验之间做好平衡确实挺难的。简单的办法是，对要暴露的接口自己做测试，在测试的过程中体会这个度。一般来说如果自己感觉都不爽，那别人是绝对不会用的。

5．接口的返回值应该是简单的语言无关的

听见过很多人问如何返回DataSet之类的复杂类型，尤其是玩.NET的人，也许是VS.NET对封装DataSet提供了过于完美的支持吧。但对于XML来说，把任何复杂对象映射到XML文档都是困难的。就好比把三维向二维投影一样，复杂性增加了可不是一点半点。在XML中说到底所有的类型都是字符串，要想表达其他类型，就要添加额外的说明。可以看看rpc/encode方式WSDL文档的complexType部分，自行体会。

6．谨慎地抛出异常

对Web Service中的任何异常都应该进行相应的处理。可以简单地归纳为以下两种情况。

第1种情况是接口返回值是简单类型，比如bool型，就true和false两种情况，不抛出异常怎么办？选择有两种，一是抛出异常，二是改变接口，返回int用1和0对应true和false，用-1对应系统异常。

第2种情况是接口返回值是复杂对象，可以通过参数out string exceptionInfo来返回异常信息。

7．接口要尽量采用更新的标准

如何让一次定义的接口能服务得更好更久？从技术规范方面来说有两点：不超前，不落伍。超前，支持它的工具集不会太丰富，估计谁也不想弄出个看起来很美但是谁都用不了的东西；落伍，眼前所有的工具大概都支持，不过明天就不一定了，技术发展这么快，不能把自己累死吧。尽量采用更新的标准的意思是在不落伍的基础上要有前瞻性。举个简单的例子，今天再采用rpc/encode方式就显得不合时宜了，虽然它在前两年很流行，可今天都已经不提倡用了，明天说不定大家就都忘了。就算你及时更新了你的接口，客户也说不定已经换了供应商了。

8．要注意标准的通用性

虽然都是一样的标准，但标准有不同的版本，而且即使是同一个版本的标准，不同的工具实现起来也还是有细微差别的。如果用户是特定的还好说，采用些工具绑定的特性也没什么。但如果接口用户不是特定的人群，那就要注意了，在采用某一规范标准时不要用实现工具所特有的东西，否则很有可能造成客户的麻烦，导致只有很少一部分客户能使用你提供的接口。多一个客户就多一分钱啊，兄弟，干嘛跟钱过不去？

9．禁用HTTP POST/GET协议

除非另外指定，否则.NET将试图把Web服务绑定到3种协议：HTTP/POST、HTTP/GET和SOAP。之所以说"试图"，是因为依赖于服务的参数和返回类型，HTTP/GET协议可能不可用。.NET生成的WSDL文件将自动包含绑定这3种协议的指令，客户程序可以自由选择使用哪种协议与服务通信。

只要在Web.config文件中加入下列内容，就可以删除对HTTP/POST和HTTP/GET协议的绑定：

<webServices>
    <protocols>
        <remove name="HttpPost" />
        <remove name="HttpGet" />
    </protocols>
</webServices>

为什么要避免通过HTTP/POST和HTTP/GET协议引出Web服务呢？主要的2个因素是安全性和互操作性。HTTP/GET的安全性不如SOAP，而且由于HTTP/GET常见于Web链接，怀有恶意的人可能利用它实施欺骗，使别人在不知不觉中用自己的安全标识调用Web服务，却还以为自己在单击Web链接。

就互操作性而言，SOAP是广泛应用的Web服务通信标准，而HTTP/GET和HTTP/POST不是。因此，对于.NET生成的WSDL文档中默认包含的HTTP/GET和HTTP/POST绑定，许多自动生成代理服务器的工具不会理解。因此，如果你的Web服务不是非绑定到HTTP/GET和HTTP/POST协议不可，最好取消这两种绑定。