标签:获取数据 其它 还需 message 统一 应用程序 git str 应该
前段时间在参加学院里的一个比赛的时候和朋友一起弄了一个简单的网络论坛项目,使用的技术有ssm、mysql、ajax、jquery、html等。刚开始的时候打算前后端分离开发,由于以前没有经验,所以就摸索着写。项目中大概是前端编写好html,不包含数据,后端提供url接口,在进入页面时调用接口,然后前端将返回的数据填写到html中。最后在项目验收的时候有被问到有没有用RESTful,虽然听过, 但是没仔细了解, 于是在网上简单了解了一下,并且记录下来。
RESTful是一种网络应用程序的设计风格和开发方式。在前后端分离思想开始增长的以后,前端静态页面需要调用指定API获取数据,而如何设计一个便于理解、使用的API成为了一个问题,而RESTful就是用来规范API的一种约束。
RESTful中,资源通过URL定位,通过HTTP方法(POST、GET等)来定义完成什么功能。
在RESTful风格中,使用同一个URL,约定不同的HTTP方法(POST、GET等)实施不同的业务。
一般情况
CRUD操作 | HTTP方法 |
Create | POST |
Read | GET |
Update | PUT/PATCH |
Deleta | DELETE |
在之前,增加数据可能是这样:(在这个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架构中,每个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 添加新的用户
对于合法的请求应该统一返回数据格式,例如返回的一个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 }
这个篇文档对设计规范有很详细的描写
https://github.com/Highflyer/REST_API_DESIGN_GUIDE
这篇文章只是自己在网上了解后写下的个人理解,如果有误希望大佬们能指出
标签:获取数据 其它 还需 message 统一 应用程序 git str 应该
原文地址:https://www.cnblogs.com/ELAIRS/p/12152444.html