曾经我以为REST就是后端只提供数据，前端负责使用这些数据来渲染视图层，以达到前后端解耦。这个理解太片面了。
就是因为我有这样片面的理解，导致我不知道如何判断“哪些数据让前端渲染更合适，哪些数据让后端渲染更合适”。
REST API不是一个解决“前后端解耦”的办法，甚至可以说，REST和前后端解耦根本没有任何关系。
REST API是一种API的规范，一种提供接口的方式，或者说，是一种提供资源的方式。
如果你的网站有一些内容，你想提供给他人使用，你才需要提供api。
像类似于这种渲染：
{% if request.user.haslogin %}
<p>一些只给已登录用户展示的内容</p>
{% endif %}
这种渲染跟api毫无关系，谁会想要从你的网站接口得到这些没用的状态信息？这种渲染逻辑上是交给后端来处理的。
先聊聊api的使用逻辑
哪些信息适合提供给他人呢？比如博客列表、每一篇博客的具体内容、每个用户的具体信息、每个评论的具体信息等等。
这些内容，就通过API来提供，换句话说就是，可以让前端通过ajax访问这个接口来获取数据，以便渲染前端页面。
还有一点就是，开发api和开发具体的app是两回事
比如，我想开发一个blog，并且开发一个api功能为这个blog服务。
那么，开发api是开发api，开发blog是开发blog，这两者之间没有任何关系。前者提供资源的增删改查，后者是使用数据，可以对数据进行处理。
这种情况下，我既是api的开发者，也是api的使用者，因为我的blog应用要使用这个api呀。
所以，正确的开发顺序应该是先开发api功能，再开发blog功能。至于说我blog要使用哪些api接口，这就无所谓了，想用哪个用哪个，也不需要把所有的api全都用上。
那么REST API和其他api的区别是什么呢？
这个很复杂，要全部理解的话要系统地读一读书，我目前的理解是这样的：
REST API是基于资源的，而"动作"早就由HTML提供好了。
基于过程(动作)的api的url是这样的：
获取博客列表 /api/getbloglist/
添加博客 /api/addblog/ 还有可能设置成/api/postblog/
删除博客 /api/deleteblog/
而REST API是这样的
/api/blog
没了，就这一个接口，就能完成上面所有的任务。是不是很清晰？
基于这一个url，我们使用不同的html动词GET POST PUT DELETE，就能完成不同的动作。其中PUT 和 DELETE需要传入博客id
所以有人这么解释REST API：“这才是html的正确使用方式”