1樓：solZ
可以使用其他工具，來規定資料格式，比如我原來在一家遊戲公司實習時，他們使用Protobu，先規定好資料格式
然後前後端根據規定的資料格式，填充資料
2樓：老藍人
作為乙個全棧，我想對這個phper說，you can you up, no can no bb。最好的結果是他幫你做了，多好。
3樓：小陳
Object.keys獲取dog和god，Object.values獲取1和2，其實是可以獲取的，不過有後端給我這樣的介面我會讓他回去重寫
4樓：Jason於航
很簡單，介面文件其實也算做PRD的一部分，是用什麼樣的方式來呈現介面（用UML或者其他方式）其實不重要，重要的是前後端雙方要約定好協作的方式。保證這份文件對前後端都是一致的。
5樓：譚承衛
你這個至少返回的是英文單詞，我們公司的php用zhong代表處理中，所有介面都是乙個方法，根據引數判斷你要使用哪乙個介面。牛不牛
6樓：
新手php還沒玩轉，不了解js裡的資料型別，所以才能寫出這麼難用的介面。
可以研究下php教他寫，或者自己寫api，或者模板甩給他自己玩去。
7樓：小芋頭君
溝通問題，如果後端自己不知道怎麼正確的返回規範的資料，你需要自己把問題都列出來，那你認為規範的寫法給他們列出來 ，這樣才能推動雙方的磨合，切勿一味抱怨，出了問題不只是後端的問題，你只是抱怨但是沒有去推動解決問題也是有責任的。
8樓：clache
一般來說php要返回這種資料要比普通正常的資料多很多步操作吧，不知道後台是怎麼想的。
其實資料格式不是問題，有的專案前端還特意需要這種格式方便取雜湊。
最主要的是專案開始前期的溝通，前後端商量怎樣的資料才是效率最高的。而且對於後端來說，資料格式的分裝相比其他端更方便。
利益相關--php後端
9樓：龍背上的騎兵
首先同乙個，後端的key裡面包含中文我都遇到過。
首先可以肯定的是後台經驗不足或者後台壓根不想寫好程式，於是就給了一堆為了業務而業務化的介面，根本無法重用。 由於結構的缺陷導致很難在實際中去使用，前端需要針對這些資料進行大量處理。
解決辦法是:
1 換人
2. 主動要求好的資料格式, 乙個介面的資料需要前後端雙端人員一起評估，不能交給乙個人處理，前端不了解資料庫結構，後台不了解實際業務需求, 一方的資訊量不足以定義好乙個介面，返回的資料盡量是結構化的元資料，這樣才能更好的復用。 名詞統一，欄位名統一。
大忌: 後台介面出現太過業務化資料。
3. 離職
10樓：Gogh
渣渣前端來答一波.... 我們公司就我乙個程式設計師，現在開始要加後台.. 然後愉快地開始了php學習之路...
左右手互相玩吧， 然後還有JS 提交前攔截驗證，pho後台接受後判定... 加油你可以的看不慣他自己去學學php ...
11樓：iceman
剛開始看到，還以為是我之前的同事！... 我們之前遇到乙個寫php的大叔和樓主描述的一毛一樣，對，是大叔，73年還是72年的，兼職的php程式設計師。
自己還開了一家小飯館，所以經常給我們回覆郵件都是在半夜。
合作的效率非常低，寫的介面經常出問題，並且我們找到問題反饋給他之後，他會偷偷的改過來，然後回覆我們說，「我這裡是一切正常的呀，沒問題呀，你自己問題吧」。
給的介面欄位都是通過翻譯軟體翻譯的（據說他不會英語），給的資料只要有資料就行，不管什麼格式....，給的資料格式經常是這樣的[....]，有時候某個介面突然之間他就會把介面資料改過來，改成正常的[obj1, obj2....
]，那時候我還在做android，被他坑怕了。
那時候年輕，還通過郵件跟他鬧過一次。
12樓：蔡俊傑
發現少帶個id欄位就讓他帶上，沒什麼好糾結的，缺胳膊少腿到底少了哪些，列出來跟他說一下，說完把事情幹完就成，長期相處，大家都耐心一點。
13樓：
你獲得了乙個鍛鍊遊說能力的好機會。
去遊說你的領導，或者領導的領導，讓他相信目前的狀況極大限制了開發效率，已經成了公司業務發展的瓶頸（不要只談技術），並且丟擲乙個完整解決方案，拍胸脯說把這件事交給你，一定出成果。
要讓你的方案落地，領導只是一方面，後端買你的帳也是必須的。所以，丟擲方案之前，去遊說後端，讓他相信你的方案能減少他的工作量，壓縮聯調時間（很多時候加班不是因為自己有活，而是為了配合聯調），並且不需要他做什麼改變（至少初期是這樣）。
這事兒成了，你就可以開專欄，吹什麼「企業級web應用介面設計與開發流程」了。
如果不成呢？不成也可以吹啊。
14樓：daryl
你有我絕望？我後端寫好介面前端讓我改成另一幅鬼樣子還說我不改他就不做。我很絕望啊。附上他提供給我它需要介面的結構
然後是我本來提供的介面是這樣的
,,求求你們前端了能學點計算機基礎再來寫前端麼改介面的時候差點吐了……
15樓：
覺得這個問題是乙個開發流程的問題，開發流程中應該約定好資料返回，如果之間有矛盾要及時提出來，請示上級開評審會，對於那方修改方便改哪方，其實也就是乙個溝通方面的問題。
16樓：
開發流程不科學，沒有文件。首先產品定義好需求，然後設計設計出原型圖，然後前端寫靜態頁面，需要呼叫別人的介面的，要讓別人寫好介面文件，接著自己開寫，這樣才不會扯皮！
17樓：張賀
私以為前後端開發前應該做好約定，包括返回資料的格式、字段、方式。相互之間是partner的心態，力求共同合作完成好專案開發工作。在某個功能無論用前端手段或是後端手段都能實現的情況下，需要權衡開發周期、開發效率等因素，交給成本較低的一方負責。
作為技術要有自己的技術立場，不能完全聽之任之。後端打過來的字段無法使用，配合態度消極，勇敢的say NO。
18樓：小擼
記住，對於前端，後端的資料都是不可信的，反之亦然。多商量，處理資料不存在哪端的問題，比如檢視層資料，使用者訪問放客戶端，分布每次計算一次，如果放服務端，假設一台機子，嘿嘿～一般情況下，還是讓後端處理好裝資料吧，你還要考慮互動呢。
19樓：林嵐
其實，這種人在公司一般都是遭人嫌棄的。當然如果是你遭人嫌，那麼勸你早些離開這家黑作坊。如果是第一種情況，那就很完美了，顯示出你的謙和與優勢。然後你就知道發生什麼了。。
20樓：謝揚輝
[,] ??? 如果是用php的陣列的話得 [['god'=>1], ['dog'=>2]] 才會這樣呀, 他自己都不好遍歷呀, ['god'=>1, 'dog'=>2] 這樣子多方便, ,,,
21樓：黑溜兒
後端對著原型和前端一起商討，後端出文件，文件一定要嚴格編寫並且前端要做到吹毛求疵，欄位名避免通過名稱猜意義，後端要盡量多的給注釋說明。結構粒度要控制好。可以使用swagger把json schema定義好，使用express+mockjs搭建mockserver模擬api做互動，用json-structure模組比對真實api和mock資料存在的結構差異。
22樓：花萼橫江
後端水平問題。
為什麼不是經驗問題。我也做過一段時間後端restful ，現在也正在做。總的來說，後端做介面這一層，不僅要保證正確，快速，安全，還有乙個最重要的但是總被忽略的--可讀。
好不好用，能不能用，對於乙個具體的介面需求，自己思考下，頂多前端講一下，要是還不懂，就是智商問題。
後端的API，不是非得要貼合前端需求，資料格式不是說要拿過來就能直接放UI，但是起碼要能人能讀得懂吧。
前端做的爛，誰都看得出，後端做的爛，那只有前端背鍋了。所以，知道該怎麼做了吧
23樓：eechen
就事論事,就算是 [,] 也一樣能遍歷,以jQuery的each函式為例:
PHP:
foreach(['god' => 1, 'dog' => 2] as $k => $v)
jQuery:
$.each([,], function(k, v)jQuery:
$.each([,], function(k, v));
輸出:god => 1
dog => 2
24樓：Roman
若真如題主舉例的這樣，那介面肯定有問題，這個他改掉責無旁貸，這個還指責別人真是厚顏無恥了。我給介面發【｛1:key｝，｛2:
value｝】這樣的引數他也很難受吧，互相感受下，能解決吧。
流程不對這屬於正常情況吧，只有大公司才會安排穩妥全面的流程吧，而且大公司還抱怨流程繁瑣呢。沒流程是不好，但別就因為這個就辭職了啊
其實感覺很多撕的情況是資料庫讀出來的與業務要求的資料格式有差異，後台做格式化也行，前台做格式化也行，然後都想對方做，遂撕。這種情況看撕逼實力了。
25樓：
到了後期才溝通返回格式，我覺得是流程問題。先定義，再開發。把所有介面整理出需求、規範並形成文件，然後可以各自開發，只要最終結果都遵守約定，剩下的無非就是細節溝通。
26樓：後除
開會的時候提一提這類事情，看看領導能不能協調解決了。
如果這種事情發生的概率比較少就忍忍好了，多的話就走人吧，不然太痛苦。
27樓：一大碗豆漿
我之前也很煩這個，後來兩邊都用typescript寫，中間有個層是兩邊都編譯的。這樣介面資料被強行對的上，不然編譯都通不過
28樓：是使用
還是開發不規範引起的
我也做過前後端分離的專案, 而且還只是小專案都要寫API文件.
落到白紙黑字上的東西, 撕起來可以糊他臉上
29樓：2gua
這問題我們也遇到過，而且遇到的還更慘，除了題主的問題，還有TXT格式、XML格式，啥都有，此外，還是跨部門合作。
如果是本部門內的，相對還好解決，忍無可忍時就把問題公升級。跨部門就扯皮拉筋得多，最後也是兩種結果：
1. 能忍的就用繞來繞去的臨時方案替代解決；
2. 不能忍的就是兩手一攤明確告知對方不行，你得改！
總之，臨時方案是相對脆弱和混亂的，後續需求、介面稍加變化都可能出錯，等出錯了看看對方改不改、這個責任誰來背，反正出來混總是要還的，除非他離職否則他也得深陷其中。
再說說介面雙方的主體問題，一般而言，前端是業務資料入口及出口，請求響應的格式（介面）都應以前端考量點為主導，所以介面的制定上，要麼由架構師角色從使用者角度設計，要麼由前端為主設計，此時後端為輔。
所以，有時候像老時代一樣也挺好的，就是按業務功能縱向分工，一人領走幾個功能模組，前後端自己從頭擼到到尾，雖然模組間、功能間也有橫向互動，但扯皮已經少很多了……
此外，這後台開發算不算是有辱PHP啊？（逃
前後端分離，前端如何判斷登入失效？
IT老魁 首先token失效跟403稍微分開看 403是乙個http返回的狀態碼，表示訪問的資源被禁止訪問，沒有許可權訪問 token失效這個token是你自己程式控制的，當前端訪問後端資源的時候，後端根據前端傳遞的引數或者token的id或者session id等資訊判斷登入時候有效，如果失效就禁...
前後端分離，如何處理前端的異常？
IceWilder 看了前面的回答，我不知道題主表達的是什麼意思。如果是服務端出現異常，返回相應的JSON前端邏輯根據不同的Code之類的去按照自己的邏輯處理就可以了。如果是超時的問題，即比如發乙個ajax請求，不知道是服務端掛掉還是響應未結束，可以設定乙個Timeout,然後一般這麼寫 promi...
現在前後端分離趨勢下，後端還要學習前端嗎
小小虎 肯定得了解呀，不然後臺就不知道要給前端返什麼型別的資料，我之前就遇到過乙個後台，一點都不懂前端，什麼東西都讓前端做，返給前端的資料都不規範，本身很簡單的json資料，硬是給了一組4維，操作起來太tm麻煩了 已登出 不學client side沒關係，但是http你得學，cookie怎麼用你得知...