前言
最近在做APP端API修改，修改內容是要在APP畫面上多顯示一個欄位。當時想說:那我就多回傳欄位再請APP端地RD去接欄位。於是改完很開心想說可以直接發PR了，結果就被擋下來QQ
被擋下來的原因是:因為APP要接欄位很複雜
我聽到直接問號????????想說不就接個欄位是要多複雜?於是開啟了再次修改API的路，但今天沒有要討論後續怎麼修改xD是要來跟大家分享當時被擋下來真正的原因
一知半解，到底是多複雜?我就問
本身是寫網頁版，所以通常改完都可以興高采烈發PR，如果code review過了就可以上測試環境順便放鞭炮，待QA測試通過和PM宣布上版就可以直接上版，因為網頁版的server是自家公司自己建立的，所以只要公司內部通過審核就可以上版。
APP的server是綁google或apple，所以當內容有更新就要發版，如果只是上到測試環境，那就是公司內部自己審核過就好，但當要發版上PRD時就一定要讓google或是Apple審核!因為正式環境的server是掛在別人身上阿~為了自家品牌和APP品質就一定要花時間審核。原來這就是麻煩的地方啊啊啊!
所以根本不是什麼APP接欄位很複雜嘛，到底是誰在騙我(其實是你自己聽話聽一半，不然就是你誤解別人的意思!)
上面的資訊都是在詢(盧)問(小)負責ios RD才挖出來的秘辛(?!)
當然也順便問了一下APP端如果要接欄位要怎麼處理。其實跟我想得差不多，就是在model給對應的key跟value，和網頁版前端接後端資料很類似。
本來聽說如果後端API多回傳欄位可能會造成APP端報錯。(對沒錯又是聽說)
和ios RD確認之後果然跟我一開始推測一樣(你以為你是柯南?)，API可以多回傳欄位，只是看APP端要不要接而已，如果沒接頂多沒有顯示。
結論
先感謝解答我的ios RD!以後如果要改APP使用的API可以先往用現有的欄位去做更改(增加或組合內容之類的)，畢竟發版真的是偏麻煩阿xD
以上內容如果有誤，請協助指正! 感謝
