以前只知道不管是API還是SDK，直接呼叫就行了，還沒有具體想過其中的區別：

SDK和API都是類似於公共服務的東西，都代表的是一種封裝，只是封裝的形式不一樣：

SDK的封裝是在客戶端層面的一個library(也叫做“包”或者“庫”)，這個library提供一些客戶端API介面，類似於已經寫好了的函式，你只需要呼叫它就好了。SDK暴露出來的介面都是和語言相關的，如果SDK是用Java寫的，就需要用Java去呼叫那個函式；如果是SDK是用Objective-C寫的，就需要用Objective-C去呼叫那個函式。

API是封裝在服務端層面的library，從網路服務的層面暴露出一些API介面，提供給使用這些服務的人去呼叫。因為封裝在服務的層面，傳輸資料用的是網路協議（常用HTTP/TCP），就不需要管他是用什麼語言實現的；

舉個SDK的例子

SDK和API都是服務的消費者；提供SDK和API的都是服務的提供者，會根據消費者的意願來定義SDK和API。

比如支付寶，很多App、網站等消費者都需要使用支付這個功能/服務，但是又不想自己去開發這個東西，那麼支付寶就說“你們告訴我，你們需要使用的環境是什麼樣的”；有人說“我是App，Android寫的”，有人說自己是iOS，有人說“我是Web的”，還有人說我是Windows的，那麼支付寶說：“沒問題，Android的我有Android的SDK，你把這個SDK嵌入到你的程式碼裡，我有一些Java的介面，Java接口裡面有個函式叫pay，然後你傳一些值給pay就可以了；如果你是iOS的，我還有另外一個叫iOS支付寶的SDK，你把它嵌入到你的iOS的App裡面，然後裡面有個Objective-C寫的函式，也叫pay，同樣傳引數進來就可以了；如果你是Web的就可能有個js的SDK，嵌入到你的HTML程式碼裡就好…”

SDK的缺點

缺點一：

SDK的不便性在於，他和App一樣，是需要升級的，比如修復某些bug，就需要讓所有用了舊SDK的商戶在更新自己產品的時候採用新的SDK。

但是SDK的升級是做不到強制性的，所以SDK提供方的人就很痛苦，因為需要向下相容很多個版本，有的時候會直接通知死都不升級的消費者商家說：“老版本的我不支援了，要用的趕緊升級！”強勢的SDK提供方，比如Facebook，會提前一年和你說某個SDK一年後不支援了。但實際上，就算給了一年的時間，很多消費者廠商還是很難完全更新他們使用的SDK，因為有時候採用了舊版本SDK的App的使用者數目太大，總有一些量的使用者並不願意升級。

缺點二：

因為SDK是完全封裝好的，提供的是一個二進位制的包，使用SDK的消費者廠商完全不知道他的實現細節。

有時候使用一些小廠開發的SDK非常有風險，如果其中有一些“手腳”，消費者是不知道的。上次有個做廣告變現的小廠開發了一款可以幫助變現的SDK，變現方式是用了他的SDK之後，彈一個廣告給使用者，如果有使用者點廣告後會得到廣告提成。但是這個小廠接廣告的模式是直接下載apk，根據規定是不能直接繞開Google Play去下載apk，Google因為這個原因，把所有集成了這個SDK的App全都下架了。 所以，如果SDK的提供方做了一些違反政策的事情，就會把完全不知情的你牽連，所以很多人不願意整合小廠的SDK，只願意整合Facebook，Google之類大廠的SDK。

缺點三：

理論上，SDK提供方可以做到，知曉消費者廠商的使用者規模。

因為消費者廠商的使用者也算是提供方的使用者，所以如果SDK提供方在實現中加入一些資料上報的動作，技術上來說是完全ok的。而使用者規模、使用者資料等都是非常隱私的東西，消費者廠商肯定是不想被別人知曉的。

為什麼要用API

接上面所說，那麼為什麼還有人願意用小廠的SDK呢？

因為有時候，某些服務只有某些小廠才提供，Google類的大廠並不可能提供所有的服務。

這個時候，API來了！可以直接用網路API，而不是在自己程式碼裡整合SDK。意思是，pay的函式自己寫，這樣由消費者自己控制實現的原理。

舉個例子，支付寶除了SDK，也會提供像API的網路介面。如果你不想整合SDK的時候，也可以自己花時間去實現支付的邏輯，API提供方可以告訴你，需要先呼叫這個API，得到某個資訊之後，再呼叫另外一個API，拿到另外一個資訊，再呼叫下一個API，拿到下一個資訊…這中間可能有好幾個步驟，最後完成pay。

相比之下，如果用SDK的話，可能只需要寫一句話就好；

如果使用API的話，每句話都需要自己寫，可能需要幾百行程式碼，但是實現邏輯都可以自己控制，中間停住也行，再插入一個廣告也行….介面怎麼跳轉、有沒有動畫都可以自己決定，只要最後呼叫提供方的API就可以了，所以很多廠商覺得這樣的形式也挺好的，只是要求會比較高一點。

另外還有一個不用SDK，而用API的可能原因：有時候，由於某些服務提供方自己並沒有封裝SDK，而API相對來說比較通用，比較方便提供。

舉個例子，如果消費者是windows的平臺環境，那麼SDK提供方就需要提供windows的SDK，但是如果提供方公司並沒有開發windows的程式猿，就只能讓服務消費者使用API。

什麼時候一定要用SDK

Q：是不是SDK能做到的事情，API都能做到？

A：不會。有些SDK裡面會提供介面，比如Facebook提供變現的SDK中，會固定他的原生廣告形式，比如大圖、文字的字號大小都是固定的，頁面會以他規定的方式展現出來。像這樣的時候，必須要整合他的SDK，因為介面和規範已經寫好在了SDK裡面….

如果是API的話，你可以拿到圖片和文字之後，可以把圖片弄很大，文字弄很小之類自由控制廣告的展現形式，這樣的自由是Facebook不願意的，所以Facebook不會願意提供API，而是需要你整合SDK。

簡單點來說

SDK對指定功能的實現是完全隱藏的，只需要呼叫介面函式，傳進去特定的值即可實現提供商制定好的功能

API可能會包括許多個介面函式，這些函式需要按照提供的規則進行順序呼叫，所以在呼叫不同函式的期間可以插入自己定製化的程式碼。