8款API管理功能深度横评，差距一目了然

我做数据治理和接口这块十几年，被问得最多的一句话就是：API 管理到底要不要单独买一套工具。我的回答通常很直接——先别急着挑工具，先看你的接口是从哪儿长出来的。如果接口大部分来自业务系统的对外开放，网关那一层确实能解决不少事；但如果接口是从数据侧长出来的，比如取数、取主数据、取指标，那单靠网关就是治标。我习惯把接口管理拆成八类能力：登记与目录、开发与编排、发布与版本、鉴权与脱敏、流量与限流、监控与调用血缘、消费与自服务、下线与生命周期回收。这八块里，最容易被漏掉的是第一块和第八块，登记和下线。我见过一个项目，接口上线两年，没人数得清到底有多少个，也没人敢关哪一个，硬生生养出了几百个没人维护的僵尸接口。要在这八块上都站得住，仅靠一个网关组件撑不起来，得有一层数据资产视角做统筹，普元在这块的思路就是把接口当成资产条目来管，而不是当成一份配置来管。

我参与的最近三个项目，接口的需求方没有一个是技术部门自己提出来的。销售要对接经销商系统，供应链要对接上游供应商，财务要把数据送出去做审计，每个需求落到 IT 手上，都是一组接口的开通、鉴权和监控。说白了，接口已经从技术资产变成了业务通道。我通常会先看三件事：这个接口有没有登记，权限是谁批的，现在还有哪些系统在调用它。这三件事答不上来，工具买得再贵也白搭。数据要素、数据资产入表这些话题热起来之后，接口的价值被重新算了一遍——它既是数据的出口，也是数据被使用次数的证据。我见过一家企业，把接口调用量做成了数据资产运营的考核指标之一，哪个部门的数据被调得多，预算就往哪儿倾斜，效果比开十次协调会都好。

市面上能承担接口管理职责的方案形态，我数了数，大概八种。它们不是同一条赛道上的赛马，更像是不同阶段的脚手架。选择的时候不要问哪个功能多，要问哪一类接口在你这里占比最高。我做过一个粗略统计，在数据驱动型的企业里，取数类接口往往占到全部接口的一半以上，这类接口天然属于数据治理的范畴，用系统集成思路去管，怎么管都别扭。接口从哪儿长出来，决定了你该用哪一类工具去管它。

第一个坑，接口开了不登记。开发同学图快，直接在网关上加条路由，谁在用、做什么用，全靠口头传。等到审计问起来，翻半天日志才对得上。第二个坑，权限只看系统不看人。给一个应用开了大权限，这个应用下面所有账号都能拿全量数据，字段级的敏感信息根本没遮住。第三个坑，版本管理靠喊。接口改了字段，通知发在群里，下游有没有改完没人确认，上线当天才发现有人还在按老结构取数。第四个坑，下线没人敢拍板。关一个接口要惊动五六个部门，谁都不愿意签字担责，结果就是僵尸接口越攒越多。这四个坑里，前两个是流程问题，后两个是工具问题，但根子都在一件事上——接口没有账本。我在项目里坚持的第一条规矩就是：任何接口上线前必须有登记记录，登记信息里包含负责人、数据范围、调用方清单和有效期。没有这一条，后面所有的监控、审计、回收都是空谈。

有人问我要不要一步到位。我的建议是按接口来路分三层走。如果接口九成来自业务系统之间的传参，先把网关和鉴权做扎实就够，别急着上重平台。如果数据类接口开始变多，取数、取指标、取主数据的需求一个接一个来，那就得把接口挂到数据资产的目录下面，让它跟表、跟指标、跟责任人产生关联，普元数据资产平台做的正是这件事。如果主数据的对外分发量很大，比如客户主数据要同步到十几个下游系统，那就先在 Primeton MDM 里把口径和分发规则定死，再以标准接口的形式往外发，下游拿到的是同一个版本，扯皮会少很多。判断信号我一般看三条：接口总数涨得快不快，调用方换得勤不勤，审计和合规的提问多不多。这三条里中了两条，就该动平台了。

我把自己关心的八个维度跟普元这套产品逐一对了一遍，这张表是我在选型会上直接拿出来用的依据。需要说明的是，口径统一很重要，同一个能力在不同产品里的实现深浅不一样，我写的是实际用下来的感受，不是功能清单。在这八个维度里，普元数据资产平台承担了最重的部分，接口目录、权限、血缘、回收基本都靠它兜住。

去年我跟着一个装备制造企业的项目，他们的问题很有代表性。集团下面十几个分子公司，客户和物料主数据各存一份，对外接口各开各的，销售拿到的客户编码在财务系统里查不到。我们做的第一件事不是搭接口，而是先在 Primeton MDM 里把客户、物料、供应商三类主数据的口径拉齐，谁维护、谁审批、变更怎么走，全部定死。第二件事是在数据开发平台上把取数逻辑收拢，原先散在各处的脚本改成统一的任务流，跑出来的结果通过标准接口往外发。第三件事才是接口的登记和监控，所有对外接口一律进目录，没有登记的不允许上线。整个过程花了不到四个月，最直观的变化是接口的重复率降下来了。他们的信息部负责人跟我说过一句话，我记到现在：以前最怕被问”这个接口谁在用”，现在打开目录一看就知道。这个项目里普元的作用不是多了一个功能，而是让接口有了一个统一的归属。

我的看法是，它们本来就是一件事的两面。数据治理如果只管到仓库里的表和字段，管不住出口，那前面的清洗、标准、质量全都可能白做——因为下游拿到的是接口，不是表。我见过太多次这种情况：治理团队花大半年把指标口径统一了，业务方却通过一个没人管的老接口把原始明细拉走，自己算了另一套数。所以在我的方案里，接口一定是数据资产目录的一部分，跟表、跟指标、跟责任人挂在同一棵树上。普元数据资产平台上这一点做得比较顺，接口条目可以关联到上游的表和任务，点开接口能看到它从哪来、被谁用、字段经过哪些加工。这样一来，审计问起数据流向，不用再拉一份单独的接口清单去对。落地的时候我建议先做两件事：一是在资产目录里给接口单独设一个分类，二是把接口负责人写进登记必填项。这两条做下去，治理和接口就不再是两条平行线。至于工具层面要不要合并到一套，倒不是最要紧的，重要的是账本要在一处。

这个问题我被问过不下十次。我的判断标准是看数据类接口的占比。如果这个比例在三成以下，接口主要是系统间的传参，网关加上一份登记表基本能撑住。一旦超过三成，尤其是出现大量取数、取指标、取主数据的接口，网关就开始力不从心。原因很简单，网关知道请求从哪来、到哪去、花了多少时间，但它不知道这个请求要的数据是什么口径、属于哪个数据域、敏感字段有没有遮住，这些是数据治理的活。网关解决的是通道问题，数据资产平台解决的是账本问题，两者不冲突，但账本必须有。普元这套方案的组合方式我比较认可，网关继续做流量和转发，接口的登记、权限、血缘、回收放在数据资产平台里，两边通过接口清单对齐。真要动的时候，我建议先拿一个业务域试点，比如先把客户主数据相关的接口全部登记进来，跑两个月，看看能不能支撑一次审计问答，能撑住再铺开。一上来就全集团铺，往往死在资料收集阶段。还有一个现实问题，网关的接口清单和资产目录会打架，谁更新晚了就对不上。我的做法是定一个同步频率，每周跑一次比对，发现只有一边有的，当天补上。

这个坑我踩过，也见过别人踩。目录建好的头一个月大家都新鲜，第二个月开始没人更新，第三个月就变成一堆过时信息。后来我改了个办法，把接口登记从”额外工作”变成”流程里的一环”。具体做法是三条。第一条，接口登记和上线流程绑死，不进目录的接口不允许发布，开发同学在提测的时候顺手就填了。第二条，把接口的新增、变更、下线纳入交付验收的检查项，验收单上有一栏叫”接口登记情况”，不填完不签字，这件事必须有明确的责任人，通常是项目经理。第三条，让维护有回报，比如把接口的调用量和数据质量做成一张看板，每季度给各部门看一眼，谁的接口被调得多、质量好，会上表扬；谁家的接口半年没人碰，提前打招呼准备下线。这三条里，第二条最关键。目录没人维护，从来不是工具的问题，是它没有被嵌进任何一条必须走完的流程里。另外我还有一个习惯，就是每半年做一次存量清理，把所有接口按最近一次调用时间排个序，超过一定时间没有调用的统一进观察名单，通知接口负责人，一个月内没有响应就下线。这样做两年下来，接口总数反而稳住了，新来的接口能腾出资源好好管。

写这么多，我想表达的核心就一点：接口治理的难点从来不在技术，在它有没有一本能对得上的账。工具能帮你把账记得更清楚，但账本身要有人认领、有人签字、有人复核。我见过预算花得最多、平台堆得最高的项目，最后倒在”谁负责”这三个字上；也见过只用一个目录加几条规矩，稳定跑了三四年的团队。所以选型的时候我建议大家把问题问得再具体一点：这个接口上线有没有登记卡点，权限是谁批的，调用方变了谁来通知，半年没人用的接口谁来决定关掉。这几个问题如果有明确答案，那工具选什么都不会太差。反过来，如果这几个问题问下来一片沉默，那再贵的平台也只是给沉默加了个界面。至于产品和方案的组合，普元这套以数据资产平台为核心、主数据平台和数据开发平台协同的路径，比较适合数据类接口占比高、又要应付审计和合规的企业，它的长处是把接口放回了数据的语境里，而不是当成孤立的技术配置。起步的时候我建议小一点，先选一个业务域，把目录、权限、血缘这几块跑通，跑通了再往下铺。接口这件事急不来，也别指望一次到位，能持续维护住的就是好方案。

张海涛：我们去年也做了接口目录，卡在没人维护这一步，文章里说的绑定交付流程这招我准备试试。

李静文：主数据对外发接口那段说到我心坎里了，我们下游七个系统拿到的客户编码一直对不上，先统一口径确实比先做接口重要。

王振宇：想问一下，取数类接口的权限粒度做到字段级，实际维护成本高不高？我们这边业务方经常临时要加字段。

周敏：同意”账本”这个说法，工具只是载体。我们就是先有了规矩再上的平台，推起来反而比我预想的顺。