API ( Application Programming Interface ) 的功能：
請求、回傳對應資訊
可以把 API 想像成是一個軟體 (App/Web) 對外溝通的服務台、對外接口，負責回應外部的特定呼叫的服務。前後端的溝通通常需要 API，兩個系統的整合或資料交換，多數時候是透過 API 來進行。告訴我你要什麼，你把我需要對應的東西傳送給我後，我就會將相對應的資料回傳給你。溝通的方式就想像成：
step1. 我到國稅局請求個人身家財產資料證明 ( 呼叫 API_name )
step2. 櫃檯窗口給我一張表單 ( 對方 API 請求對應資料 )
step3. 我完成表單上要求填寫的資訊 ( 回應對方 API 請求資訊)
step4. 櫃檯窗口開始以他的 know-how，執行必要動作在國稅局的資料系統裡找到我的資料 ( business logic programming )
step5. 把個人身家財產資料證明以有浮水花印的紙本文件格式給我 ( return value )
API_name{ p1,p2, p3…..} >>business logic >>return value
所以 API 通常會有 4 個部分 = API 名稱、API 輸入參數、編寫商業邏輯取得對應資訊、將請求資訊以對應格式回傳給呼叫端。
封裝資訊
這裡就是上面提到的 business logic 的部分，當我不想讓別人知道我的演算法和我的主機是怎麼儲存內部資料的，有哪些欄位，我就會封裝他，自己處理成呼叫端需要的資訊，至於是怎麼處理的，我會有內部的商業邏輯know-how，但不會分享給外部的人。就像國稅局不會告訴我他是怎麼查到我的所有個人身家財產資料的，他也不會告訴我他還有哪些資料欄位。
隔離資料庫
用 API 來限制呼叫端在允許的商業邏輯下取得資料，限制部分資料庫開放存取權限，才能確保資料庫的安全性和穩定性。
API 與 API 的對話，就彷彿人與人之間的合作協議。
資料庫 ( Database )
3 種資料結構 ：結構化資料、半結構化資料、非結構化資料
結構化資料
就是常見到有明確欄位名稱定義的表格，就像我拿到一個 excel 檔，所有資料都清楚的分門別類好了，我可以把它轉成各種我想要的視覺化形式，或用樞紐分析去看我想要找的商業邏輯洞察，是分長容易做分析的資料形式。
半結構化資料
當今天有兩個不同的程式語言、兩個不同的開發環境、兩個不同的資料規格，就會有半結構化資料的存在，都是為了方便交換與資料溝通。就像上面提到，有時候會遇到要系統整合或前後端溝通，那要用什麼資料格式溝通呢？這就像是我習慣用 slack 來管理與工作上利害關係人的溝通資訊，但我的主管可能習慣用 email 來管理溝通資訊以及相關檔案的分享，業務同仁可能覺得用 line 溝通最方便，如果每次都要轉換平台效率就會變慢，所以我們會溝通一個共識的協作方式。回到資訊傳輸來說，就是把所有可被轉譯或解析的資料都先以字串(string)的方式儲存，方便在收到呼叫端請求資料的時候，就可以很快的把資料給他，只要格式被宣告清楚，對方再自己做成他想要的格式即可。
非結構化資料
我們常說的質性訪談資料就屬於這一類，或者我們常聽到的 social listening 的工具，也是在處理非結構化資料的相關性和相關顯著性的問題。
理解自家的資料結構，會讓 PM 更有彈性的去運用手邊的資料來規劃內外部的合作資源。
資料庫變更需求的種類
新增資料庫要考慮「完整性」
新增資料庫欄位是比較常有的需求，與新增相關的需求要考慮到「完整性」，才不會讓工程師覺得你怎麼不一次講完。但並不是說不能變動，所以 PM 再提出變更需求的時候，背後的商業邏輯就要跟團隊溝通清楚。就像新創公司面試的時候常會問到一個問題就是，我們可能策略會變得很快，你可以接受嗎？我認為策略的改變本身不是問題，但領導者能不能說出策略改變背後的戰略思維，就會決定團隊對這個改變的信任感，而不是只是說因為我們要有營收，所以要改變。同樣的，如果一個產品經理有辦法對工程師溝通他在這個改動與上一次改動之間所衡量的商業邏輯是什麼，就可以讓這樣的溝通方式成為團隊文化和共同語言。
刪除資料庫要考慮「連動性」
許多人會覺得刪除資料庫欄位很簡單，但這一類的需求要考慮到的是「連動性」。尤其在變動快速的新創公司內，產品團隊成員來來去去，剛開始資源不足的時候一定是用最簡易也最有彈性的開發方式。有時候上一個人是用什麼邏輯去呼叫、給予對應資料的，要待很久的工程師才會比較了解來龍去脈，有時候可能 RD 主管自己都要問底下的工程師。這時候 PM 就可以多問一句，會影響到其他資料的呈現嗎？會影響到當前的用戶體驗嗎？更有 sense 的 PM ，在了解自家主機儲存資料的方式之後，就可以問的更具體，也幫團隊把關。
編輯資料庫要考慮「必要性」和「替代解法」
編輯資料庫的需求是這三個裡面最讓工程師頭痛的，所以可以的話要盡量多提問，試著引導工程師發想替代性方案。當然，說起來簡單，到底具體怎麼判別替代性方案，最後通常只有工程師知道。 PM 能做的，就是盡可能地增加自己對資訊架構與開發環境框架的理解，用一顆好奇心去提問，建立好的信任合作關係。
其實還有很多可以說的，有空再回來補上 SDK 和 Data Layer 的概念。
