比如我覺得資料有冗餘，讓他精簡一下，不用全部都發出來，還有希望有些資料能經過二次處理的
回複內容：
這對他來說的確是最省事最簡潔最有效率的做法，看不出你的勝算在哪，，，
@vczh 的方法是無效的，因為首先產品狗根本管不著伺服器端傳什麼資料，需求變更只會傳達到前端，所以這個程式員的做法是以不變應萬變，他把資料庫直接暴露給你了，所以除非需求要修改資料庫，他都完全不用修改任何代碼，而如果需要修改資料庫，他的修改也非常簡單。
這種情況，正確的反駁方式是用海量的請求對伺服器端發起DoS攻擊，令其不得不縮減傳輸資料大小和增加緩衝來改善效能。
如果你的DoS也不能讓對方失去響應，或者你們根本沒有這麼大的流量，那麼說明他的設計就是合理的。那這個問題就只是兩個程式員工作量分配的問題了，這事兒應該找你的上級去反映。
任何設計原則其背後一定有其原因，拋開情境談原則的架構師都是十足的騙子——Ivony。設計介面時的確有不要太精確地配合前端的需求的動機，為了介面有一定的一般性。只返回前端需要的欄位，那麼前端增加顯示內容就要變更介面；把資訊按前端需求格式化好，那麼前端變更呈現方式就要變更介面。
當然，介面最小化可以節省伺服器頻寬，可以為擴充和schema變更留出空間，可以防止前端依賴內部實現細節，這都需要取捨。
此其一。
你今天要求他介面最小化，明天需求變更，你又去找他增加返回資料，你多麼被動。
他今天堅持返回所有資料，明天伺服器壓力太大，他找你商量哪些資料可以砍掉，他多麼被動。
此其二。
誰幹活，誰說了算，誰為自己的決定負責。你最多盡到提醒義務。他以後發現自己決定錯誤，想精簡介面，你又沒有增加工作量，你基本上連利益相關者都算不上。
此其三。來，伺服器端程式員來說話了
這事我們真要具體情況具體分析
1、那個伺服器端程式員工作的時候爽不爽，例如我現在很不爽，不是特別要緊的話，我就直接SELECT * 給你了，有冗餘的或者需要二次計算的，你自己在用戶端去搞，這事關情緒，當然也顯得特別的不夠Nice~~但是講Nice的話，是不是有人對伺服器端不夠Nice呢？
2、這個API有多個用戶端或多處在調用，為了照顧通用性，確實直接SELECT出來給你最好，並把結果在伺服器端做個緩衝，這樣一來大家都能調用，由用戶端做二次處理。例如你只需要其中3個欄位，但其他人卻需要5個欄位，這個時候你說如何取捨呢？當然我可以把包含5個欄位的結果全部緩衝起來，當你來調用的時候我二次處理只給你返回3個，但，這個又會涉及到我爽不爽的問題了（其實我是真心覺得沒什麼必要，無關情緒）……
把一些非核心的計算交給廣大人民群眾手中的用戶端去做，我覺得特別美啊~~讓產品狗給他上幾個需求變更你就按照他的設計邏輯，讓他把口令也這麼傳到前端，然後在前端判斷是否登入成功。這根本就不是個技術問題。你讓人家多幹活，人家自然是要反抗滴。說什麼都是借口罷了。你要是給人家付加班費，估計就好說多了。服務端，用戶端都做。
所以呢，個人經驗是，找上級或者找產品都沒意義。關鍵是你先理解對方為什麼要這麼做。如果是你，你會不會這樣做。雙方理解是最關鍵的。別佔著你認為你是對的這條路子一直走。沒用的。。。人家的思路毫無疑問也是對的
我做用戶端的時候是每次都讓服務端儘可能的把資料給我，然後我來分析。除非不好弄，協調一下，對方也會響應。你幫他，他就會幫你。。
所謂開發，也是和人打交道，除非都是一個人開發，那是另一回事。
上面說的比較虛，來點實際點的。
給多資料有什麼好處呢？
1.服務端開發肯定方便很多，加欄位減欄位而已
2.認識的你就要，不認識的你就不要。暫時不需要的也丟棄掉。以後擴充，服務端不用動，只需要你調整就行。否則，兩邊一起改。這個開發成本不是1+1=2.是1+1>2的。
前面同學說：
DoS攻擊的說法，不好意思，沒用。多一個位元組少一個位元組在DoS下沒明顯的區別。人家DoS的目的是拖垮你，如果沒做DoS防禦。這個借口什麼都不吐，光http的頭就能弄死你。
簡單可依賴。。
除了一種情況。移動端~~~~移動端區別是非常大的。。流量就是錢。你可以說：“得了，你不用開發了，直接讓我把SQL拼好了傳給你吧”
呵呵呵呵
————————
正經回複：
如果放在哪會影響程式效率，你們之間是服務調用關係，這個時候如果有資料證明在服務端最佳化傳輸後能提高效能、節省成本，可以反駁——如果老闆不認為省錢比快速上線重要的話你也沒轍，是不？
如果對效能沒影響，那麼一定程度上可以理解為過早最佳化，這時候更多的矛盾在於你們的工作量和工資之間的比例關係，我認為這個問題需要上級來解決。
那我覺得發請求最好寫中文，比如
?"給我客戶的資料，謝謝"
就是這樣的啊、、、、、、
