SpringMVC–SSH -- RESTful -- JSR303
最近在使用SpringMVC+MyBatis感觉用起来效果很好。我不太明白SpringMVC和SSH的关系，遂搜索了一下。原来使用SpringMVC之后，可以替代之前的SSH这种开发模式。
然后看到RESTful风格和JSR 303
之前指导RESTful风格，但是一直不知道此物为何物。今天研究了一下，附上两个链接：
这是个人对RESTful的拙见：
简单来说就是Restful风格是一种编程时候的约束，你的编程时候的URL地址等因素符合Restful提出的这一套标准，那么你就是rf风格的编程。
通常我们通过向URL地址发送GET请求，向服务器请求一个资源。服务器给我们返回比如html,txt,excel等等这种格式的资源（输入网址返回显示的页面其实就是请求服务器返回一个html文件，再由浏览器去解析），同理我们通过向URL发送POST请求，将本地的数据发送到服务器。其实我们和服务器之间只是一个资源上的交互。
其实Http 1.1协议还支持一些其他的请求方法，比如：DELETE，PUT等等。
借用阮一峰博客一段话：如果客户端想要操作服务器，必须通过某种手段，让服务器端发生"状态转化"（State Transfer）。而这种转化是建立在表现层之上的，所以就是"表现层状态转化"。客户端用到的手段，只能是HTTP协议。具体来说，就是HTTP协议里面，四个表示操作方式的动词：GET、POST、PUT、DELETE。它们分别对应四种基本操作：GET用来获取资源，POST用来新建资源（也可以用于更新资源），PUT用来更新资源，DELETE用来删除资源。
其实通过这种方式，我们就可以客户端的HTTP请求，对服务器上的一些数据进行修改（更新或者删除等）而不是之前单单的通过GET和POST和服务器进行一个资源上的交互。
你也许会说比如我想删除一个资源，那我向后台传递数据的时候加个字段，后台再去判断不就好了吗？其实这样完全可以，但是这不符合Restful风格了。
下面说一下JSR 303
JSR 303介绍：
JSR 303 – Bean Validation 是一个数据验证的规范，2009 年 11 月确定最终方案。2009 年 12 月 Java EE 6 发布，Bean Validation 作为一个重要特性被包含其中。本文将对 Bean Validation 的主要功能进行介绍，并通过一些示例来演示如何在 Java 开发过程正确的使用 Bean Validation。
通过IBM的文章，我知道了JSR 303是一个数据校验的规范。然后小白的我又迷糊了。既然在前台页面我们使用过JS对数据进行校验，那么后台为什么还是需要对数据进行校验呢？
通过百度得到答案：
验证是分为两部分的，客户端（浏览器）验证也就是JavaScript的验证，和服务器验证的（你的例子里就是Struts2验证框架了）。
验证的目的一方面为了保证用户输入的正确性，其实更重要的是防止攻击。
而JavaScript的验证，只要让浏览器禁用JavaScript就可以绕过了，所以会有安全漏洞。因而必须要有服务器端的验证了（除了验证以外，一般还需设计一些代码防止如SQL注入攻击之类的。前一段爆发的Struts 2的某版本漏洞，你百度一下应该知道它的危害）
但是，服务器端验证有提交这一步，运行速度上比简单的JavaScript浏览器验证要慢，所以JavaScript验证一般也是需要的，让用户有更好的体验。
综上，对于一般成熟的商业程序来说，服务器和客户端两个验证都需要，原因就是这样。
原来是JS校验可以被绕过，那么使用后台再进行校验，可以防止一些黑客的攻击手段。
今天又涨姿势了。
