摘要

介绍个人背景，项目背景，有什么痛点，决定用什么技术解决痛点

2011年上半年，我在上海中软资源软件有限公司（ICSS），作为项目组长参与了公司人事管理（HR）系统的开发。在系统开发前，公司在信息化建设中，也已采用请假流程、薪资管理、招聘系统、虽然较为成熟，但彼此之间相互独立，业务数据无法共享。且公司各个分公司间，对HR系统使用情况也截然不同，有的分公司由于各种原因，依然采用手工管理本应信息系统化的业务流程。公司是以软件外包业务为主，所以人力资源管理系统在公司信息化建设者中的地位至关重要。这次开发的HR系统，将整合现有的业务系统，在整个公司内部推行使用，已解决信息孤岛带来的效率低下的问题。为了以后的扩展需要，保证在业务和空间尽可能大得扩展性。因此，经过研讨，决定采用REST Web服务方式实现系统应用层。本文将就HR系统的开发过程，描述一下对REST服务的使用和认识的机会。

正文

介绍项目情况，介绍项目采用的架构的顶层设计

中海中软HR管理系统整体采用基于B/S的三层架构设计。

我作为项目组长参与系统需求分析至测试和部署的整个过程，直接向IT部门总监汇报。负责沟通需求，建立项目组，确定系统架构风格和技术实现方案。预定开发周期为120天，系统部署后有两个月的试运行期，项目组人数在5-10人间变动。由于项目开发资源（比如时间）紧张，公司HR系统业务逻辑复杂，旧系统改进与新需求交织，项目组对业务并不熟悉，难以在一开始预估将所业务移植到新系统的时间。因此，在开发模型选择上，采用螺旋式增量的开发。首先不必追求大而全，在开发完系统基本框架基础上，优先移植最急需改进的业务。经过与领导和HR部门的沟通研究，递交了系统准备实现的功能列表，按不同实现优先级排列，标记为P1的功能优先级最高，必须实现。比较为P2/P3/P4的功能优先级依次降低，必要时可以根据资源情况需要进行裁剪。

详解技术结构

在开发技术的选择上，由于本公司业务以微软外包为主，公司的开发人员大都熟悉一项或者多项的微软开发技术，作为微软公司合作伙伴可以低成本的获取软件开发和管理工具，方便的获取技术支持。所以决定该系统采用微软技术：表示层基于 ASP.NET4.0; 中间业务采用REST服务实现，基于WCF（Windows Communication Foundation） 4.0;数据访问层基于微软的ORM构件-AEF（ADO.Net Entity Framework）4.0。在构件的选择上，尽可能降低开发工作量，提高效率，力求避免把精力放在通用的技术细节上，而是放在业务逻辑的研究和实现上。

详解系统的物理架构模型

系统部署共有三台服务器: 两台Web服务器 Windows Server 2008 + IIS 7.5, 分别运行系统网站以及REST服务；一台数据库服务器 Windows Server 2008 + SQL Server 2008。经过试运行，于7月份投入正式使用。目前系统状况良好，经运行评估，实现了全部必须功能，性能、安全性等质量均达到了原定设计要求。目前系统正在根据业务需要，由后续项目组做二次开发中。

介绍老技术的痛点

采用REST服务方式系统业务逻辑层，完全符合项目非法时考虑的两个因素：简单和灵活。传统的Internet Web服务一般基于SOAP协议，构造SOAP请求XML岁软前 .NET Framework 已经实现了较好的封装，但不便非.Net语言调用，如客户端页面中大量采用了Ajax技术，使用JavaScript构造Soap请求非常困难。在调用服务的Web页面开发完成前，为了调试和测试服务，碧玺写单独的测试程序，十分不便。

介绍新技术的好处以及优点，并且解决了痛点

相比之下，而REST服务具有非常出色的灵活性。技能被服务端面向对象语言调用，又可以直接被客户端的搅拌语言调用。也很方便用浏览器和Fiddler工具进行测试。我们在项目中，并没有将REST服务单纯视为一串地址的相应，但基于HTTP协议，可以最大的利用HTTP协议的语义特性。如数据的增删改查操作对应不同的Http Method(Put/Delete/Update/Get)。用户可以用相同访问服务节点（EndPoint），根据需要，通过在请求头中设置不同的Accept-Type,获取不同形式的数据结果，比如JSON（用于Ajax）或XML（用于后台）。

更好的性能和缓存支持，由于不需要构造Soap消息，请求Rest服务显然开销更小。REST类Web服务可以利用高速缓存控制头，从而减少带宽的需求，从而REST可以改善响应时间和改进用户体验。

可扩展性和无状态性，每个请求都是独立的。一旦被调用，服务器不保留任何会话，这样就可以更具有响应性。通过减少事件后的通讯状态的维护工作，调高了服务器的可扩展性。

开发中遇到的小问题，以及解决的方案

在为系统开发REST服务时，也遇到一些问题：

一、 安全性方案。并不是指REST的服务安全性不足，其本身没有内置的安全支持，但所有HTTP支持安全模式和框架几乎都可以用于REST服务。真正潜在风险存在于REST灵活的使用方式上，既可以被服务端调用又能被客户端调用，所以一开始就要明确地区分用户访问权限和系统访问权限，区分Web页面权限和REST服务权限，但有时在开发中经常混为一谈，所以要加强设计阶段这方面的文档和评估工作。

二、服务接口规范性。REST服务基于URL地址访问，有非常强的语义性，服务接口的每个操作都基于一个URL模板。在实际业务中，功能类似的操作被做成多个重载，随之重载的增多，URL模板如何约定，如何扩展便成为一个规范性的问题。开始时，对此未予以足够重视，在多人开发服务，以致一些服务操作语义产生了混乱，影响了理解和正确的使用。后来，又额外花费时间资源统一了规定了操作Uri格式。这一方面，源于业内无明确的标准，更重要的是，应该从设计时就全面考虑将来如果需要重载等功能的扩展，URL模板的语义扩展方式。还有一些其他的规范问题，诸如一些操作包括增删改查中的一种以上的数据操作，HttpMethod如何定义，也应该一并考虑。

三、WCF REST 自身限制。WCF从3.0发展到4.0，已经是较为成熟。而WCF的REST构件，则是全新的技术，WCF作为.NET平台WebService的代替者，无论在开发还是管理上，都极大地具有灵活性。而WCF REST的灵活体现在开发和使用上，在管理维护情况下，WCF REST服务接口操作未提供如WCF一样的灵活的配置功能，URL模板等元素必须在代码中设置，消息格式虽然可以根据客户端请求输出，但不能再配置文件中设置。

总结部分

总的来说，虽然REST服务仍然在发展中，经验与技术还有很大的进步空间。但毫无疑问，基于REST服务的WEB应用程序拥有很多的优势，未来在WEB系统，将有更光明的应用前景。