用产品思维设计API（一）——RESTful就是个骗局 前言
最近公司内部在重构项目代码，包括API方向的重构，期间遇到了很多的问题，不由得让我重新思考了下。
- 一个优雅的API该如何设计？
- 前后端分离之后，API真的解耦分离了吗？
- 不断的版本迭代，API的兼容性该如何做？
年前，我司内部的接口已经进入了一个完全的重构阶段，参考了市面上各大平台的API和文档，自己也总结出了很多的心得。这里向大家分享一下，接下来一个月，我们向从下面几个方面向大家介绍一个优雅的API（至少我认为挺优雅）该如何设计。
RESTful就是个骗局
数据解耦，才是前后分离的本质
版本控制，没有你想的这么简单
随意定义错误码，你还在这样干？
安全，就只能用HTTPS？
ps. 打一个广告，公司内部现在在招聘各种技术岗位，Java、Android、前端等，待遇保证能让你涨30%，有兴趣的朋友可以加我微信，二维码在文章最后。
Ok，今天是第一篇文章——再看RESTful。
回顾一下HTTP协议基于HTTP协议的API使我们在开发APP、网站中最常见的形式，为了更好的了解如何设计一个良好的API，我们这里先简单的回顾一个HTTP协议。
先抓包看一个请求demo我们用Fiddler抓了一下360浏览器的任务中心的API接口信息，如下是它的请求信息：
POST http://task.browser.360.cn/online/setpoint HTTP/1.1 Accept: */* User-Agent: Mozilla/4.0 (compatible; MSIE 6.0; Windows NT 5.1) Pragma: no-cache Content-Type: application/x-www-form-urlencoded Host: task.browser.360.cn Content-Length: 449 Cookie: T=s%3Ddaf1a2e6347e01ebccc72d639441f9ef%26t%3D1456561881%26lm%3D%26lf%3D1%26sk%3D03714c868adc12684c89a65c05bc7709%26mt%3D1466821360%26rc%3D4%26v%3D2.0%26a%3D1; zsmodel=MI%20NOTE%20LTE; zsosv=4.4.2; __guid=243694361.1257306006931263000.1482113838601.9001 stamp=1482151473&qt=Q%3Du%3Dfgpubh%26n%3D%25PO%25QR%25P9%25R1%25P0%25RS%25O5%25P4%25PO%25N7%25O9%25S8%26le%3Dp3EwnT91WGDjZGLmYzAioD%3D%3D%26m%3DZGZlWGWOWGWOWGWOWGWOWGWOZwDl%26qid%3D29340825%26im%3D1%5Ft013ba372ccf308e7b6%26src%3D360se%26t%3D1%0D%0AT%3Ds%3D76f8c61854f171f63f66a8f552962e8e%26t%3D1456561881%26lm%3D%26lf%3D1%26sk%3De79c0ecb263d447d96e85f23825c3924%26mt%3D1466821360%26rc%3D9%26v%3D2%2E0%26a%3D1&verify=6fce1222e64cefa2b5b3d24d65fa9eb1得到的服务器响应结果，如下所示：
HTTP/1.1 200 OK Server: nginx/1.6.3 Date: Mon, 19 Dec 2016 12:42:58 GMT Content-Type: text/html; charset=utf-8 Transfer-Encoding: chunked Connection: close {"errno":"0","errmsg":"success","lastpoint":"2016-12-19-20-42"}这里，没有任何文档我们也能够直接的看出来。大概步骤是：
1. 浏览器向 发起了一个 POST请求
2. 该请求中附带了一些cookie信息，也带了一些自定义的消息体
3. 响应结果是正确的，返回给浏览器一个JSON格式的数据。
对于一个完整的请求（Request）、响应（Response）来说，还是有一定的套路的，这里我们看一下HTTP请求和响应的规范格式。
