距离上一次写博客过去了好久，今年伊始带人做项目（我也菜。。），发生了很多很多事，难得偷偷请假放松一天。

    感悟分三点：对REST的理解，对项目的理解以及对管理的理解。

    （1）对REST的理解。

        第一次听说REST是在去年秋天。准确的说，当时项目要求是用Web Service实现一个文件自动传输功能。这个功能很好说，简单的描述就是一个‘数据库+存储文件的文件夹+一个类似于windows服务的服务’。讲真，我找相关资料找了好多，还是没有理解Web Service。此时大佬说准备采用Apache Axis2，那就研究一下咯，一段时间后对它的初步印象就是一个RPC，然而由于功课原因我也没有深入研究Axis2（不是借口。。。）。

        上一学期过得很快，奔波着考试吧唧吧唧的，就完了。在考完试后，仔细研究了一下RPC，大概知道了它的运作方式。

        RPC与XML可谓是天作之合。XML可以完整的描述一个信息，RPC通过XML，把需要调用的服务器的方法和请求的数据全部封装到XML里面，举个例子。

    
     
      getSinglePerson
     
     
      personStaffId
     
     
      personUserName
     
    

        当然这个例子是随便写的，只是想解释以下XML可以清晰的说明想要进行什么操作。这也体现了XML比JSON可读性好太多。据悉很多企业应用还是使用RPC传输方式了，不过前景嘛，当然是下来会出场的REST。

        REST，这里我就不粘贴那么多概念了。菲尔丁博士的论文，看的似懂非懂。简单的来讲，REST中文译名为表述性状态转移（脑中出现了状态机。。），其实我感觉，只要理解了HTTP，就能理解博士所说的HTTP，毕竟博士参与了HTTP规范。

废话好多，以下正经起来。

        HTTP中，最精华的规范为“把一切当作资源”。我们用浏览器浏览页面，页面是一个资源，而类似于天气预报的数据也是资源，只不过因为页面被浏览器解释了，呈现给我们的是视图，而单调的数据没有视图。

这就让我们加深了对HTTP的认识，以前我认为HTTP是为浏览器服务的，即HTTP是浏览器与远端服务器进行通信的协议，而HTTP，其实也是一个动词，即传输资源的动作。就如上面段首所言，一切都是资源，HTTP把资源传送到本地。还有，HTTP使用很广泛，而且这么多年没出现什么大问题，也证明当初的设计是非常正确的。

        理解了‘把一切当成资源’以及‘HTTP是动词’，然后就来讲述为什么REST很符合未来的趋势。今天中午看了一篇文章叫做“谷歌发布云端API规范”，打算用REST来替换RPC，虽然还需要假以时日，但是趋势已经显现出来了。为什么REST好呢，举个例子，就比如最近在搞的一个重构项目，把原本用传统Struts2+Hibernate实现的项目重构为RESTful的，为什么要重构？比如，我们计划在其中开发一个Android APP，可是按照以前的方式，需要专门开发一套与Android通信的系统。这样浪费时间和精力，并且以后维护的时候需要同时维护Web通信系统和Android通信系统，想想就麻烦。。。企业是在合法的情况下追求利润最大化的，在以后升级之时肯定需要彻底重构减少成本。

        还没有讲到REST的好处，REST的缩影就是HTTP。把一切当作资源，把一切作成服务。我理解服务为24小时不间断的函数，给你一个输入，返回一个输出。而且这个服务，是无状态的。为什么要做成无状态的，众所周知，HTTP也是无状态的，只是传输，不在乎你的状态，并且底层是TCP/IP协议。无状态很好的把前端后端解耦。举个例子，最近在设计RESTful API，可是我一直想不通前端怎么接受呢，，，如果要按照MVC的思想，，，终于有一天，幡然醒悟，本来考虑的就有问题，我是要把它设计成无状态的，那我为什么考虑前端的问题呢，这样设计的API就不是REST风格了！然后又想，如果按照MVC方式，相当于客户端把会话状态（我理解之为前端和控制器耦合，，不知道对不对啊，，，大神请指教）传输过来，这样我就考虑几个问题了，这样也不属于REST了，所以都错了！！！

        又扯了一段，我们假如把所有数据设计成资源，就像HTTP一样，那么我们不就用一套通信方案就可以了？例如需要得到库存信息，API为getStocks（），APP可以调用此方法，PC可以调用此方法，这不就缩减好多成本了嘛？我们只需要告诉其他开发人员我这个格式就可以了阿。

        理解了统一接口，然后就是理解URI。就像HTTP一样，资源都有一个地址，例如localhost/index，在这个地址背后就是一个资源。我们把REST设计成一个个的API，是不是也可以通过资源定位符来定位资源呢？当然可以啦，我们也可以用URI来标示资源阿？（URL是URI的子集）其实这点不严谨，动作+资源才能唯一定位资源，为什么？对资源的操作无非几种而已，GET，POST，DELETE，PUT，还有OPTIONS询问操作方式。

/*********************************************/

今日更新

        说到这里，可以引伸出REST的真实用途了。把一切当成小小的服务（暂时没有研究过微服务，所以叫小服务）。REST的真实含义是提供统一的访问接口，无论客户端还是手机端，统一访问这个接口得到相关的数据（我目前将数据例如list或者object全部格式化成JSON），客户端只用解析相关JSON,然后就知道你请求得到的东西了。为什么不用XML？XML太大了，可读性好但是传输效率太低。

        REST这种风格是为了什么呢？是为了访问的便利而已，你的业务逻辑还是那样的逻辑，只不过对其他人暴露的接口得到的都是JSON等等，统一了风格。例如你进行查询操作，后台依然是“查询数据库+返回结果”，唯一的区别就是可能像我一样用FastJson将其格式化为JSONString，然后传输给对方。当然，资源的访问方式也不太一样，一般使用URI来标记资源的位置。

        我感觉这些东西就是REST的思想子集，，，目前开发遇到了一些例如资源设计的问题，例如数据库表与资源之间有些耦合，资源设计没有很明确很易懂。项目计划月底完工，完工之后给大家分享最后怎么设计的。

/

关于对项目的理解

        软件工程最大的风险在于无法真正控制其风险，当我们认识到风险的时候，基本快晚了。。。---Shual Liu

        本人经历过软件的腐烂，深有体会。鄙人也开始感觉写代码只是很小一方面，如何保持团队协作，如何保持软件规范，以及如何设计可复用的软件，各个都是学问。

        在现在文明中，很少能见到一人独立完成一个项目了。集体的力量更大，我时时在想，我不能认为自己觉得他们进度太慢就全盘包办代替了，这是不对的，更好地方法是让他们每个人多产出20%，这样自己可以把更多的时间花到设计上，以免后来会出现架构级缺陷时为时已晚。

        在现今这个小团对中，产出效率很低，大部分人没有学习过集合，设计模式等东西。隐隐约约感觉很棘手，因为很担心代码质量不达标，可是事已至此，又该怎么办呢？还记得很有印象的一句话，软件永远不是完美的，只能一步步让它完美。其实在有限的时间内做出来一个基本称心如意的，已经很符合我的期望了。

        其实说到底就是规范的问题。就算他很差，有了规范，也能一步一步写出差不多的代码。鄙人前几天详细讲述了以下命名格式，包管理，源码注释，源码头文件注释等等，在规范之中进行（目前没看到效果呢。。。）

   //未完待续