SSM+RESTful+ajax——开发Java Web

　　前段时间在参加学院里的一个比赛的时候和朋友一起弄了一个简单的网络论坛项目，使用的技术有ssm、mysql、ajax、jquery、html等。刚开始的时候打算前后端分离开发，由于以前没有经验，所以就摸索着写。项目中大概是前端编写好html，不包含数据，后端提供url接口，在进入页面时调用接口，然后前端将返回的数据填写到html中。最后在项目验收的时候有被问到有没有用RESTful，虽然听过， 但是没仔细了解， 于是在网上简单了解了一下，并且记录下来。

什么是RESTful：

　　RESTful是一种网络应用程序的设计风格和开发方式。在前后端分离思想开始增长的以后，前端静态页面需要调用指定API获取数据，而如何设计一个便于理解、使用的API成为了一个问题，而RESTful就是用来规范API的一种约束。

　　RESTful中，资源通过URL定位，通过HTTP方法（POST、GET等）来定义完成什么功能。

　　一般情况

　　在之前，增加数据可能是这样：（在这个controller类中是有声明外层RequestMapping的，实际访问URL 应该是 post/addPost）

1 /**
2      * 发帖
3      * @param post
4      * @return
5      */
6     @RequestMapping(value = "/addPost",produces = "application/json; charset=utf-8")
7     public @ResponseBody String addPost(HttpSession session,@RequestBody Post post){
8         //具体操作省略
9     }

前端使用ajax，访问/addPost  URL进行数据的增加。

　　Spring4.3之后，为了支持RESTful风格，增加了@PutMapping、@GetMapping、@DeleteMapping、@PostMapping这几个注解，可以直接将method属性和@RequestMapping绑定，先在增加数据可以这样：

1  @PostMapping(value = "/{id}")
2     public @ResponseBody String addPost(@PathVariable Long id){
3          //处理数据
4     }    

　　这样只需要通过POST访问post就能实现增加数据的功能。

RESTful规范

　　1、参数命名规范

　　　　参数使用驼峰命名法或者下划线方式命名。

　　2、url命名规范

　　　　在RESTful架构中，每个url代表一种资源，每个url代表一种资源所以url中不能有动词，只能有名词，并且名词中也应该使用复数。实现者应使用相应的Http动词GET、POST、PUT、PATCH、DELETE、HEAD来操作这些资源即可

不规范的的url，冗余没有意义，形式不固定，不同的开发者还需要了解文档才能调用。

https://example.com/api/getallUsers GET 获取所有用户
https://example.com/api/getuser/1 GET 获取标识为1用户信息
https://example.com/api/user/delete/1 GET/POST 删除标识为1用户信息
https://example.com/api/updateUser/1 POST 更新标识为1用户信息
https://example.com/api/User/add POST 添加新的用户

规范后的RESTful风格的url，形式固定，可读性强，根据users名词和http动词就可以操作这些资源

https://example.com/api/users GET 获取所有用户信息
https://example.com/api/users/1 GET 获取标识为1用户信息
https://example.com/api/users/1 DELETE 删除标识为1用户信息
https://example.com/api/users/1 Patch 更新标识为1用户部分信息,包含在body中
https://example.com/api/users POST 添加新的用户

　　3、统一返回数据格式

　　　　　对于合法的请求应该统一返回数据格式，例如返回的一个json数据应该包含：

　　　　　　　code —— 包含一个整数类型的HTTP响应状态码

　　　　　　　status —— 包含文本：”success”，”fail”或”error”。HTTP状态响应码在500-599之间为”fail”，在400-499之间为”error”，其它均为”success”（例如：响应状态码为1XX、2XX和3XX）。这个根据实际情况其实是可要可不要的。

　　　　　　　message——当状态值为”fail”和”error”时有效，用于显示错误信息。参照国际化（il8n）标准，它可以包含信息号或者编码，可以只包含其中一个，或者同时包含并用分隔符隔开。

　　　　　　　data——包含响应的body。当状态值为”fail”或”error”时，data仅包含错误原因或异常名称、或者null也是可以的。

返回成功的响应json格式

1 {
2   "code": 200,
3   "message": "success",
4   "data": {
5     "userName": "123456",
6     "age": 16,
7     "address": "beijing"
8   }
9 }

返回失败的响应json格式

1 {
2   "code": 401,
3   "message": "error  message",
4   "data": null
5 }

　　4、http状态码

• 1**请求未成功
• 2**请求成功、表示成功处理了请求的状态代码。
• 3**请求被重定向、表示要完成请求，需要进一步操作。 通常，这些状态代码用来重定向。
• 4** 请求错误这些状态代码表示请求可能出错，妨碍了服务器的处理。
• 5**（服务器错误）这些状态代码表示服务器在尝试处理请求时发生内部错误。 这些错误可能是服务器本身的错误，而不是请求出错。

　　　　　https://github.com/Highflyer/REST_API_DESIGN_GUIDE

原文地址：https://www.cnblogs.com/ELAIRS/p/12152444.html