【经验分享】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