【经验分享】RESTFul实践以及数据库字段兼容设计与字段预留

1. RESTFul与API设计

RESTFul是一种架构设计风格，它有多个实现层级，最常用的领域在于前后端交互时的API设计。
API一般有两层含义：一是指语言或者框架的使用方法（如JAVA API文档），描述了语言或框架的函数调用接口；而是指远程调用的接口地址。

RESTFul有两个最大的特征：面向资源操作以及无状态，本次分享只涉及到面向资源操作。

RESTFul将请求抽象为资源操作，比如我们百度搜索“学习”，其实是在向百度服务器中的 “学习”【资源的查询】操作。

资源基本操作包含四种：【查询】、【添加】、【删除】、【修改】，分别对应HTTP方法的【get】、【POST】、【DELETE】、【PUT】（其实这个并非RESTFul规定的，而是实践中最常用的模式）。

但是，实际上，“将请求抽象为资源操作”有时候并不好使用。比如如下两个接口设计：
POST www.baidu.com/login
POST www.baidu.com/user-access-token

第一个一看就是登陆的接口，而第二个表示增加一个user-acces-token资源，隐含意思就是登陆（当我们登陆时，增加了一个登录凭证）

RESTFul不允许在地址中写动词，但是很多具体的动作抽象成资源，本身具有一定的难度，而且可读性较差。

实际当中，包含动作的接口非常多，并不仅仅限于基本的增删改查，要求将复杂的动作都归结到简单的增删改查上面，但是每个人对这些动作的理解可能不一样，这就导致最终抽象的资源难以理解。
尽管RESTFul看起来十分火热，然而真正完全遵循它的大厂基本没有，RESTFul最佳实践的GitHub，也是用了动词的 。

最常用的是混搭风格：动作+资源抽象。
保留【查询】、【添加】、【删除】、【修改】，分别对应HTTP方法的【get】、【POST】、【DELETE】、【PUT】。
保留动词。

用户操作：
查询： GET /user/get/1
注册： POST /user/register
登录： POST /user/login
删除： DELETE /user/remove/1
批量查询： POST /user/list

2. 数据库字段兼容设计与字段预留

主键ID：如果没有自增逻辑，使用varchar（方便分布式）
时间：使用时间戳 long
价格：使用decimal，保留两位小数。不要使用Double ，float ；java里面BigDecimal
状态、布尔值、性别等：用0、1、2、3…表示的值，如果没有构建字典表，不要使用数字，直接用真值。类型用char。
类型：使用char，不考虑动态扩展类型时不要增加type表，在服务端使用枚举。

字段预留：图片、备注、新增时间、修改时间、被谁新增、被谁修改、状态、逻辑删除

mysql时间戳的使用
https://www.cnblogs.com/orac/p/6433874.html