通俗易懂告诉您什么是SDK和API？
日期：2020-02-06 栏目:信息流 浏览：次
随着企业营销数字化转型脚步越来越快，SDK和API也会被使用的越来越多。
概念定义
大家可能经常在企业数字化建设过程中听到API这个词，可能对于非技术出身的同学，不是很好理解。打个通俗比方，可简单理解为，API就是数字世界、软件世界里的插头。
应用程序接口（Application Program Interface (API)）就是连接各种软件系统，为了能在各系统之间共享数据而开放的技术接口管道。API主要是针对数字产品和服务的，其目的是为了能让两个要通讯和共享数据的系统平台，按双方都认可、认为合理、有意义、可理解的方式，发送和接收彼此的信息。
有许多使用API的场景，举个常见的例子：营销人员会希望将Web和移动App分析的数据，都推到数据可视化平台中，以图形化方式展示出来，这就需要使用API接口，接入这些数据。
SDK（Software DevelopmentKit）是指系统为了便于别的系统对接他们的API，而提供的一系列软件开发工具包，甚至软件开发测试环境等等的总称。
打个比方
既然是插头，那首先要有接口协议对吧，例如电源插头是220V还是110V的。有过国外旅游经历的同学想必应该有感受的，国外很多国家的插头制式规格同国内不同，需提前准备好转换适配装置，国内制式的插头才能使用。如下图所示：
所以我们可以将API接口协议理解为这种规格制式，然而仅有制式规范还不够。一般插头都是配对搭配使用的对吧？而API大家可以简单理解为，是在这组配对组合中仅有单件是现成的（如仅有插座缺插头），即仅有一方（插头一方或插座一方）提供了现成可用的物品。如一方已提供插座，就需要另一方按接口协议规格制式去研发插头，然后才能将插头与插座很好的配合使用。这个插头-插座的连接配合，就是API对接。
试想，若是从头研发插头，那么跟插座适配肯定需要一个联调适配的过程，从不上电的物理接口适配，到上电后的工作状态，甚至异常电流、温度、湿度等特殊安全情况下，都需要测试以确保万无一失。
可见这个过程若研发插头的工作由原研制插座的团队来完成，肯定效率会非常高的，因为他们在生产插座时，为了测试，肯定已经有了插头最起码的可用交付物。自然再进一步大家就能联想出：他们还可以提供一整套的现成可直接工作可用的插头的成品/半成品（甚至便于测试测量的工具等），提供给到那些需要对接到该插座的厂商们。这样这些厂商们就不需要再重复研发插头了。这个现成的插头的成品/半成品就是我们常说的SDK。
讲到这里，大家应该对API及SDK的区别有个大体的了解了吧？
2.在此之上是对接双方基于接口通讯协议实现的发送和接受的一组API接口程序；
3.某一方为了便于技术对接，直接提供了已包裹API接口程序的可直接工作的SDK软件包，便于对方直接使用，降低重复开发成本。
当然这套SDK需要能满足对方软件的不同工作环境的需要，例如：有Android系统App中集成的SDK，ObjectC版App中集成的SDK，Java版的、Python版的等。
广告流量分发场景
好，讲到这里，对基本概念说完了，大家肯定很多问题就会出来了。
吴老师，今天在重新看你的书温习一些概念，你书里有讲到“sdk的话媒体会丧失对流量的控制权，所以一般都prefer api”。我自己也查了一下，api经常接触也有用到，就是数据/指令传输的接口，约定了可以传什么东西、返回什么东西。但我还比较模糊的是，sdk和api对于媒体来说本质的区别是什么，为什么说用sdk丧失对流量的控制权？
是的，大家可以再回味回味上面的那段插头插座的故事，若可工作的插头模块也是我插座团队提供的，外部使用者仅仅做个简单的包装，将线接到插头，那么是否意味着存在如下几点：
1.插头这一方对插头内部已失去控制权，想在提供数据时做点手脚的成本就会加大。不是说不能做手脚，而是成本会加大，若原来插头是自己实现的话，在插头里做手脚就行了，而现在需要把做手脚的动作往前移，会从接口模块，前移到那些可能涉及业务系统的部分改造。所以可见SDK的方式会增加一定造假成本。但不是说SDK模式一定无法造假。
2.对于SDK模式，插座插头都是一家生产的，那么在生产的插头中植入一些探测器，用来收集外部其他软件系统的一些数据是可能的。甚至若SDK有UI交互展示部分的功能，额外加入一些后门也都是可能的。那么作为使用SDK这一方，SDK对他而言就是黑盒子，就存在很多不可控的风险。
3.当然提升信任，有一种做法是提供接口源代码参考，由使用方检查，并由使用方自行编译为可工作的二进制程序，在自己的系统中使用。这种模式其实还是API模式，因为使用方还是可以对代码进行修改，加入一些达到自己利益的动作。
对于第3点，有同学会说，我可以提供同时提供保持一致的二进制的SDK和源代码，这就没问题了吧？但毕竟是黑盒子，对使用方而言还是不知道你的代码都做了啥。
先要强调，背景是说的广告流量对接场景，且偏媒体立场的。
若我是媒体需要将流量对接到广告平台中，不论是对接给SSP、网盟，还是广告主的Adserving平台，我优先肯定希望我自己能有绝对的控制权，希望优先以API的方式进行对接。因为我想做什么手脚的话，相对成本低一些。
但若我的立场是SSP、网盟收流量的，或我是广告主Adserving，我当然希望能SDK方式接入流量，这样我能多采集些数据，提高灵活性（我想升级或调整一些接口策略的话，只要SDK足够兼容，完全可以不用通知对方的），最重要一点是因为我可以通过SDK采集一些数据来校验对方做手脚的情况。从而增加对方做手脚的成本。
所以对一个问题，我们需要首先确定立场，是站在哪一方的视角来回答的，可能答案会完全不同。
广告监测场景
上面提到的是广告流量分发的场景，下面让我们来看一下广告监测的场景。
实操过项目广告执行的同学肯定经常听到过API监测、SDK监测代码之类的。在看本文前可能有些同学会是一头雾水，很懵圈的吧。
API对接方式，就是媒体方按接口协议规范约定，将监测方需要的参数，在自己的软件系统中组装好，在产生广告曝光或点击时，给监测方服务端发送请求。
例如：下面这段监测代码中，有非常多的参数需要传递，如设备ID等。
http://tracking.com/x/k=&p=dx=__IPDX__&rt=2&ns=__IP__&ni=__IESID__&v=__LOC__&xa=__ADPLATFORM__&tr=__REQUESTID__&vg=__AUTOPLAY__&nh=__AUTOREFRESH__&mo=__OS__&m0=__OPENUDID__&m0a=__DUID__&m1=__ANDROIDID1__&m1a=__ANDROIDID__&m2=__IMEI__&m4=__AAID__&m5=__IDFA__&m6=__MAC1__&m6a=__MAC__&m11=__OAID__&nd=__DRA__&np=__POS__&nn=__APP__&nc=__VID__&nf=__FLL__&ne=__SLL__&ng=__CTREF__&txp=__TXP__&tr2=__REQUESTID2__&o=
而SDK对接方式，媒体方要做的，是首先在媒体的软件中集成该SDK软件包，在产生广告曝光或点击时，媒体按规范调用SDK软件包中的函数，传入一些参数，以此启动SDK去执行SDK中的软件程序，给监测方服务器发送请求。SDK模式下，就算有些数据媒体方没有传，或故意传错了，SDK自己可能也可以去采集到，例如设备ID等。
所以这也能回答另外一个曾经同学们问我的疑问：为什么有说法：
“ 对曝光监测而言，API监测代码可以认为同SDK监测代码从统计出数来看没什么区别”？
再说个之前有个同学跟我聊过的一个她们排查了很久才发现问题的故事：也是监测API技术对接的场景，媒体方自主编程开发的API对接程序。但是网络连接部分的软件是媒体的开发人员按自己的喜好，选用的网上某个现成httpclient包。而这种情况下，可能给监测方服务器发送的UserAgent，可能不通过监测方的合规性检查，监测方会过滤掉这些数据，导致媒体方同监测方产生较大的数据误差。
当然对上面这个故事，若换成SDK模式对接的话，SDK中对监测方服务端发送请求的代码监测方自己会验证过的，可能这种数据误差的问题出现的就会比较少了。
作者：吴俊
来源：程序化广告实战
