而關於介面的規定，衍生出了一大堆問題，第一是關於空值的制定，是不輸出呢？還是輸出null，還是輸出""
今天在除錯1688開放平台時，1688開放平台那邊出了兩套介面api給我們調，一套是舊的，用關鍵字deprecated標誌過時，而一套是新的，因為是最近才推出的吧。
有點坑的是，新介面雖然變得簡潔了，但是一些老介面裡面有的字段沒有返回給我，對於新介面缺失字段這種事情，我也很無奈，阿里巴巴開放平台的文件真的也是寫得一般般啊。
然後楷哥說去阿里巴巴的官方，看它官方是用什麼老介面還是舊介面，我們照著玩就可以了。
所以我就用chrome按f12去抓包了，挺無聊也挺沒效率的，以後應該會有更優的辦法吧。
在分析阿里巴巴官方的html頁面中，我發現他們的json資料都是寫在html裡面的。挺有趣的，如果把json寫在乙個html裡面，那麼前端的訪問位址就會變成只有乙個。而後台這邊json我就可以隨意地寫在html**裡面了，
雖然這種方式讓html**顯得很髒，但是似乎挺符合設計模式的「開閉原則」，只需要後台改動就可以了吧。
,objectlist:,
extradata:{}
}
最後再說一下，1688那邊似乎是用老介面的字段來實現一些東西。
介面的設計，設定前台傳給我的json格式是
requestparams{}
而我返回給後台的模式是：
responsebody
,"data":{}
具體的api規則
檢視資料 product/ verb = "get"
刪除資料 product/ verb = "delete"
修改資料 product/ verb = "put"
增加資料 product/ verb = "post"
在前後端整合的過程中，一定會碰到修改介面的情況，修改介面是一種很噁心的行為，會造成大量**的修改。因為介面是契約，契約更改了，**世界便亂了。用設計模式的拓展和封閉來講，就是已經寫過的介面不會更改，需要新資料則新增乙個介面。
只要不動用到底層資料庫的修改，其實改動量都不會很大。
設計模式是擁抱變化的。把不變的東西封裝好，把可變的變成使用者輸入，這便是設計模式應該學習的，比如用來代替之前的constant裡面的常量
API 前後端分離重構
背景 後端出現大量前端 造成邏輯不清晰，可讀可維護性差。前端採用原始的jquery開發，前端技術已經遠遠落後於市面主流技術，造成開發效率低，混亂。解決 採用主流前後端分離技術，包括 1.前端路由做流程控制 2.使用mvvm框架 做資料繫結 等等 效果 後端只寫介面，很多任務作遷到前端，前後端語言各司...
關於前後端分離
為什麼要前後端分離？記得大學時候剛開始接觸web開發時候，前端用的是html jsp，根本不懂得架構什麼的。直到畢業工作，入了第一家公司。趕上乙個專案，老框架的那種，有段時間我負責解bug。有些問題是頁面的問題，有些事dispatcher路徑沒有寫對，有些是引數格式不對。很煩的就是每次做完修改，都需...
前後端分離
關於前後端分離的一些好的文章推薦 前端框架 為什麼前後端分離 最直白的理解，我認為是因為在開發過程中，前端總是需要等待後端的環境搭建好之後，前端才能獲取相關資料，對於前端的開發影響很大，事實上前端並不關心後端的開發，那麼有沒有方法不讓後端影響前端的開發呢？其實後端提供的是什麼？乙個執行伺服器，乙個就...