開 api 規格是個有趣的事情，從欄位命名、資料階層設計、易讀性、合理性、方便性都是需要考量的點，對於BE來說，開api規格就像是在推出一件產品，而使用者是前端夥伴，我們都接過很鳥的api，所以自己會希望自己開出來的規格是盡量能夠適應變化，又給前端有好使用體驗的api

api 結構設計

目的導向：方便寫入DB vs. 易讀易理解的結構

這是最近任務做Patch API 帶來的啟發，過往在更新資料時，我會希望api req 盡可能與DB schema 相同，這樣我可以省下從req 擷取相關欄位組成需要儲存資料的過程，不過這樣的情況比較適合成熟穩定、不易變動的需求，因為每當遇到變動需求，我就需要重新調整 api req 規格，造成FE 多出相關成本來適應這場變動，只因為我想要可以不需要有資料擷取的動作．

那麼好的方式是什麼呢？
我認為是，複雜度較高的Patch Api (ex.超過一個階層的req Object)，應該以易讀易理解的結構為目標，讓FE可以快速理解，相關資料應該放到哪些物件中，而非一個規格適應不同規格，只因為可以直接存進去ＤＢ，這樣帶來的好處是，如果需求有所變動，FE 可以只針對變動部分調整，而省下因為相依性帶來變動成本

api 易讀性標註

新手時開api 只覺得，阿我給你欄位名稱就好，後來開始知道最好還標上型別，再後來知道有enum欄位最好也寫上enum，欄位命名精準好理解，也能幫助api串接正常，

後來了解到，寫的越清楚，可以省下不必要的溝通成本，讓開發者都好好專心開發，不過開發時間總會有時間壓力，究竟要寫得多完整是可以取捨的，但長期來說，我還是會期待自己可以有效的運用時間，開出一份盡可能適應變動、易讀易理解的好規格，讓串接我開的api的FE夥伴可以有愉快的串接經驗，我只能說我還在往這條更好的路上邁進，可能還不夠好，但是會越來越好der