1. 开发流程
（1）Restful风格url设计（重要）
在Rest 基础设计中，资源使用以下动词进行操作。（也就是你写方法名的时候可以用动词名词结合的方式，但是url一定要另外写，不能抄方法名当url）
创建资源 : 使用 HTTP POST
获取资源 : 使用 HTTP GET
更新资源 : 使用 HTTP PUT
删除资源 : 使用 HTTP DELETE
也意味着,你作为Rest 服务开发者或者客户，应该遵循以上的标准。
基于Rest的Controller（控制器）
我们的 REST API :
GET 方式请求 /api/user/ 返回用户列表
GET 方式请求 /api/user/1返回id为1的用户
POST 方式请求 /api/user/ 通过user对象的JSON 参数创建新的user对象
PUT 方式请求 /api/user/3 更新id为3的发送json格式的用户对象
DELETE 方式请求/api/user/4删除 ID为 4的user对象
DELETE 方式请求/api/user/删除所有user
（现在也只能理解这么多了，就记一下，除了select以外的另外三个，和简单的用id去select的方法，这也就是绝大部分了，都要用这种Restful风格的命名方法。）
这里的根源原因应该还是这些东西掌握不熟练，以及Controller里面的那些注解根本不会用，所以要慢慢练习着去使用这些！
（2）在url里面添加服务名
情况适用于，比如auth里面其实只有auth，这里面的url也屈指可数，这种情况就不用特别细分，直接auth/方法就可以了，但如果是inform、interactive这种臃肿庞大的模块，用一个模块名根本表示不了行为的时候，就用inform/questionaire/getquestionarie，可能写的不太好，但是意思就是把一系列同一功能的服务前面加上前缀，用于综合。
（3）入参约定
约定token身份认证统一传入参数模式，后端采用aop切面编程识别用户身份。其他参数一律为json。
（这个就是对于登录完了之后，在其他请求中应该添加header。其实即使是不使用鉴权中心这种方法，也能够使用header啊。）
（4）接口和impl实现类
最新的接口设计认识：
接口这个东西在最初的设计版本里面是不该有的，应该在你意识到这个服务的某一个方法会发生变化之后，然后针对这个变化来设计一个接口阻塞掉后面的变化。
原来的认识：
（接口应该先被设计出来，如果impl都写出来了然后再补一个接口这种简直没什么必要。
接口设计出来之后，再写测试用例，假装接口已经写完了，然后写一下写出来的接口应该到什么效果，然后再去写接口的实现类。）
（5） 前端和移动端使用一套接口是对的
目前的问题可能在于这套借口只是给前端用的，没兼顾到移动端。
2. Controller类里面的注解
（1） @PathVariable
巨帅气的一个注解，和上面的Restful风格几乎一个重量级。
（2） @RequestHeader
（3） @CookieValue
这一系列的注解，基本证明了只要是前端传递过来的东西，我们后端这边基本都是可以直接使用的，根本就不需要什么解析，SpringMVC早就解析好了，直接用就行了。
3. 如何处理高并发
（1）缓存
（2）服务拆分
把访问量特别高的服务拆成单独的一块，然后提供接口调用给别的服务去利用。这个服务自己一块的话，就可以使用分布式，多见几个集群来提高性能。
（3）异步
（4）分库分表
如果一个表太大了，几亿行，神仙也没办法，做一些水平或者垂直的分割。
（5）队列
用队列限制高并发，类似于限流，把请求放在队列里面去请求。
（6）池化
多线程测试
并发这个东西是可以玩儿的啊！！！
写一个for循环，每经过一次循环就生成一个线程然后运行，模拟一个并发场景。
以及既然都有并发场景了，那么那些并发的语法什么的挨着个的都可以测试了，以及包括缓存啦，队列啦之类的给并发用的东西都可以测试了。
（以及我以后如果想测试什么东西，尽量在test里面去改，别在主程序里面改了吧，改完了可以就留在那里不运行）
网友评论