簡單描述下問題情境
我想和後端介面請求使用者名稱和ID用於展示在UI上面。兩個欄位即可(userName
,id
),但是後端同學在介面中把使用者性別/地址/電話/建立日期....全部返回過來。
我想瞭解下這樣做有什麼不妥,雖然對目前前端沒有影響。
如果這樣有問題我該如何和後端同學溝通
回複內容:
簡單描述下問題情境
我想和後端介面請求使用者名稱和ID用於展示在UI上面。兩個欄位即可(userName
,id
),但是後端同學在介面中把使用者性別/地址/電話/建立日期....全部返回過來。
我想瞭解下這樣做有什麼不妥,雖然對目前前端沒有影響。
如果這樣有問題我該如何和後端同學溝通
肯定是不好!
但是後端同學在做介面的時候,考慮的問題角度不同
他可能覺得自己需要暴露更多的資料,以保證將來產品變化的時候(比如以前不需要的資料後來需要了)自己改動更小。他可能使用同一個介面應付不同用戶端的需求(app 和網站的需求的欄位可能不同)他可能偷懶, 直接把資料庫model 序列化給你了。
我只說我自已團隊的解決辦法: 前端需要有自己的‘後端’ 。 前端同學使用 nodejs 封裝出自己表現層需要的介面, 這樣的介面不多也不少,需要什麼返回什麼。
我的理解中的 “前後端分離” 並不是運行在瀏覽器裡面的js 就是前端, 運行在伺服器裡面的就是後端。
以前的普遍觀點是後端用於處理資料,前端只用於展示。但是如今伺服器的運算能力沒有顯著提升並且使用者在增加,而使用者手裡的終端運算能力在不斷提高。這樣就可以把一些資料處理推給前端。這樣用一些網路的流量來換取減輕伺服器的負擔,是完全合理的。
很有問題
如果可以通過這個介面看到別人的性別,地址,電話等等,是個很大的安全隱患
造成無謂的資料轉送和頻寬浪費(可以想象他從資料庫讀取肯定也是select * 的操作,所以這個浪費並不僅在前後端)
關於溝通的問題,你們需要一個介面定義的文檔,雙方明確約定應該返回什麼,如果有額外的返回或者缺少,以文檔說話,這比你直接指著他說出他的問題要合適的多
有不妥,欄位過多造成網路延遲增加,使用者體驗變差,過多欄位也容易泄露資訊。
但是大部分應用還是更需要靈活性,所以其實多給點欄位更好
資源浪費(如果是從緩衝讀的內容可以忽略)
安全,樓上說了,地址電話等可能會泄露
他懶
可以問他為什麼不單獨寫個方法只查詢你需要的資料
可以協商是否可以加入參數的方式在不新寫方法的情況下滿足你們各自的需求
不過還是建議跟樓上說的一樣,約定好一個介面返回什麼資料。
1、安全問題:使用者的資料飛必要,都不要暴露出來,爆出來後,第三方使用者可以爬取你們的使用者資訊。
2、網路傳輸:後端給前端返回的資料越多,佔用的頻寬或者網路流量就越多,對於使用手機流量的使用者來說,很不友好。
3、開發規範:作為一個團隊,肯定有自己的開發規範,對於不規範的地方及時溝通交流,內部強制執行規範。這樣,久而久之,會有一套屬於你們團隊的好的規範。
最好的辦法就是多寫一些介面,滿足不同的資料五萬,千萬不能做一個介面,滿足萬能資料要求,前後端都要淚奔~~~
如果你是領導可以開除他了
顯然有問題。
主要問題在於他懶啊,因為他覺得你後面會再要別的欄位(又要改),只是現在沒想到就全弄出來了。
可以考慮規定一些欄位是一定不會用到的。