最近在 Facebook 的前端及後端社團看到了一個話題「API 應該由誰來制定」的討論，也在一些前端社團上看到有人發起「前端工程師的 API 規劃活動」之類的活動，藉此就來說明一下筆者的看法：

在目前看到許多的台灣網路公司，規模在50人以下，團隊的角色分配常看到的是「Product Manager(PM)、設計師(設計)、前端工程師(前端)、後端工程師(後端)」，而 PM 通常也沒有技術相關經驗，遇到系統開發時往往就會變成工程師們自己去定義及協調。這時候常常會發現事情總是落到了後端手中，原因有時候是因為「後端比較了解資料的格式、感覺後端是比較了解程式的人」。但這個時候又會發生一件事情，後端開的 API 格式前端工程師覺得結構不能用，處理起來憋手憋腳，整體處理起來就會花很多時間，此時就會發生前端效率不佳的情況發生。

近期，就會開始有前端覺得自已要有話語權，但是也有許多前端工程師非從後端轉職，對於 API 的制定也沒有概念。

對於 API 是要前端還是後端制定的選擇，應有二種方法，以下針對二種方法進行說明：

  1. 若公司預算允許，團隊增加一位系統分析師或是由技術組長進行規劃及設計，原因在於需要由一位成員先行了解需求，再進行資料庫、後端程式及前端畫面的設計及分析，再進行「整體的規劃」，原因是因為常常後前後端分別只會以自己的角度進行規劃，雙方無法知道對方狀況，因此任何一方在設計時就會造成另一方在執行上的困難，所以就會需要有一位可以同時了解資料結構及畫面呈現的人員來進行規劃及設計。
  2. 前後端共同協調討論，由 PM 發起系統開發會議，在同一個時間點及空間前後端分別提出對於此次開發功能的需求看法，並且雙方對於該 API 各自提出格式，雙方方進行實作面的思考，確認最後的結果是可以執行的，在擬出最後的結論並文件化，執行時則依照討論結果進行開發。此方式則需要建立在前後端工程師有良好的合作思維。