一一回应：
1 get, post, put, delete 方法的细化，可以很容易在上层做权限拦截，从读取，新建，修改，删除层次上就做到了，当然这个是对方法的使用比较严格。
对于一般的资源，比如 /v1/user/1/ (几个方法表示获取，创建，修改，删除)，如果用你现在的方法，那要怎么表示，无论如何都会很冗余。
rest 是为了描述通用资源的管理，如果你抽象得好，绝大多数请求都是可以归类出来的。其他的你可以自行实现，比如你说的「传统」的 API 设计...
2 从 URL 和 Header 里分离参数是有特别意义的，比如 https://developer.github.com/v3/#authentication，用户认证的 Token 必须放到 Header，如果你放在 URL 里，这是一种不安全的方法。总之，敏感信息是不能带在 URL 上面的，类似 Token，sessionid，Header 是最好的选择。
3 Status Code的细分，你看看下面的描述，你觉得这些没有用的？
200: 正常，可能附带数据
201: 需要创建的对象已经存在
400: 请求参数或者格式不对
403: 没有相关的权限
404: 资源没有找到
500: 内部数据出现错误

总结：
大部分的麻烦，要考虑是不是代码写得不对，因为 rest 的这种规范，代码其实更好写的，以 java 为例子，非常好做继承和复用，统一的错误和异常处理，比如一旦 403 转到权限不足提示页面。

这个地方要看你对缓存怎么定义，对于使用数据库 select * from xx where id = yy 的情况，其实走的大部分也是数据库的缓存，要理解缓存的重要意义，在于访问时间数量级别的差异：比如寄存器，内存，硬盘，网络访问时间...你可以看到访问时间是数量级别的差距，这就是推崇缓存的意义。

缓存遇到的问题是：
1 粒度
粒度太小，增加了维护上的难度，粒度太大，更新频繁，内存占用大
2 副本
缓存是数据库的一个副本，只要存在副本，就存在不一致性的问题，举个例子，有人手工用 sql 语句更新某个值，而缓存是没办法通知到的。副本状态维护在计算机的各种设计上都是很大的问题，从设计上要减少副本。
3 更新机制
和 2 是相关的，没有一种很好的更新机制能非常好的把更新推送到 cache，代码会比较 dirty。

但是依然推崇缓存：
1 例子：mysql 的协议就比 memcached 复杂很多，相对来说在协议上就体现出延时。
2 大幅的减少 db 的压力，以我经验看，大部分程序员很容易把压力扔向 db，然后由数据库管理员负责，这是不对的。

缓存使用原则：
1 不要手工去维护缓存，特别是业务代码里，这是灾难。
2 orm 里面去维护缓存，做各种更新触发操作，对数据的操作只能通过统一 orm。

这个倒是蛮容易的，使用 ssh 公钥密钥，无密码认证，然后脚本读写，so easy

必须开启，因为很多服务会开放端口，但是这个端口对外界是没有意思的，举个例子，如果你启用了 mysql，通过 3306 端口的，请问你要开放 3306 端口出去吗？

不需要，Home键不能用吗？

这个是扫描，没有太好的方法，我的一般策略就是使用 2222 来替代标准 22 端口

看到这种都想免费我就想喷，https://www.namecheap.com/ssl-certificates/geotrust-ssl-certificates.aspx，一年也就是9美元，三年也就是30美元，合计200rmb以内，你细数一下你最近的消费，有没有超过200rmb的娱乐项目？这200rmb就真的出不起吗？

@chenniaoc 单线程不会成为瓶颈的，这个和网络复用有关，nginx也是单进程模式，当然你可以开启多个。
这个问题应该不难，redis生成临时计数器，按照一定时间回写到数据库。

更好的方式从应用服务入手，比如在 tomcat 里面开放一个简单的请求，然后外部检测程序去访问这个链接，如果 200 就说明访问成功

git gc 看一下先

影响 -> 印象

百姓网影响很好，是从看王建硕的blog开始的，但是上面几个同学提出了很好的问题，还有在技术方向上看起来倾向php比较多

楼主这种脾气真是我最害怕的，因为家庭（父母之间）之前存在问题，所以对争吵的环境非常敏感，更别说甩东西了。
还有，你到现在都在关注面子问题，”以后我就跟她成仇人了“，这个必须分！

阿里巴巴的呢？