曾經我以為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的正確使用方式”