无味杂谈

    距离上一次写博客过去了很久，今年伊始带人作项目（我也菜。。），发生了不少不少事，可贵偷偷请假放松一天。

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

    （1）对REST的理解。

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

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

        RPC与XML可谓是天做之合。XML能够完整的描述一个信息，RPC经过XML，把须要调用的服务器的方法和请求的数据所有封装到XML里面，举个例子。

<xml>

<method>getSinglePerson</method>

<argument>personStaffId</argument>

<require>personUserName</require>

</xml>

        固然这个例子是随便写的，只是想解释如下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%，这样本身能够把更多的时间花到设计上，以避免后来会出现架构级缺陷时为时已晚。

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

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

 

   //未完待续