接口
接口有什么用？
作为一个互联网公司，很多资源和信息需要内部共享或外部流通，那相关的数据就需要通过接口来传输。无论是2C++还是2B的产品，都会用到接口，其中2B的产品们——数据、后台、开放平台/供应链，几乎和接口都是正面接触。
接口怎么用？
目的千差万别，用法殊途同归。本文主要以美团门票举例，介绍接口的基本属性、产品逻辑和异常情况等，供大家参考和讨论。
怎么理解接口？
API接口是APPlication Programming Interface的简称，是一些预先定义的函数，包括接口地址、传入参数和返回参数。
可以简单理解为，当需要访问某些数据，正常状态下传入合格参数，会收到该数据范围内的返回参数。
场景：在美团旅游频道，用户选定时间、地点后搜索航班，后台会调用搜索接口传入时间、地点等参数，接收航班类别、价格等参数，在前台页面上进行排列展示。同理，下单时会调用生单接口确认是否成单，支付时会调用支付接口完成交易，自动修改订单状态。
产品逻辑
很多公司都有开放平台（也叫供应链），比如美团作为一个平台，很多的供应商需要把自身资源导入平台，在平台页面上集中展示，供用户选择。一般情况下，美团会有自身的一套接口，供应商可以开发对应的接口进行对接，这种叫（运价）直连。
以下以美团门票为例，此链接HTTP://open.trip.meituan.com/是商家对接的开放平台，不涉密，商家技术、业务人员可以通过该地址上的接口说明进行商家对接。
1.系统结构
门票直连系统是通过接口，把商家的门票数据导入到美团上收单，按用户行为轨迹来说，实现“搜索-预定-下单-支付-售后”的自动化。异常情况通过邮件等形式预警，手工介入处理。
（详细流程见此链接https://www.processon.com/view/link/5943ec7ae4b0bdefc0582e3e）
①正常情况下，涉及前台和用户行为的业务流程：
②涉及后台的产品数据&订单状态更新（部分简略）：
2.接口总览
按接口类型和属性可分为三类：数据类、交易类和通知类。有一部分为美团接口，另一部分接口需要商家进行开发。
数据类：商家数据对接到美团（涉及到商家的4个接口，拉取产品信息、产品变化通知、拉取景点信息、拉取价格日历）
交易类：“用户——美团——商家”的交易行为（涉及到商家的5个接口）
通知类：包括商家开发的已出票、票已使用、已退款3个接口，美团自有的已退款、查余额、编审状态通知的3个接口。
异常问题
我做过的接口产品不多，但问题类似，主要包括两类：接口问题、产品问题。接口问题就是无响应、响应过慢、重复响应等，产品问题就是存量少、变价快、时间差导致下架更新不及时等。
在做接口相关的产品时，异常与正常流程同等重要，这与核心用户和边缘用户不是一个概念。所以在考虑每一步的流程时，必须兼顾异常问题的发生与解决方法，尽量避免损害用户体验和商家损失。
一般的解决方法是数据监控，通过对每个业务节点的多项指标进行监控，一旦超出阈值，就可以用邮件、短信等形式通知相关人员，及时解决问题。
接下来我们从两个方面具体探讨如何应对这些问题。
1.用户体验——具体场景&数据监控
对用户来说，流程的任一节点不顺畅，都会导致体验不好，故根据用户行为轨迹来进行数据监控。
①页面展示慢——接口响应时长、用户页面停留时长、跳失率
Reason：实时调接口查询景点&产品信息，因数据量大或频率快导致。
Solution：缓存数据，每N分钟更新一次。
②数据展示异常——后台返回接口异常的次数和概率
Reason：接口超时或异常。
Solution：可以设定重复调用，多次重试失败后，通过邮件等形式通知到运营、技术或商家。
针对数据型接口，对产品进行下架或隐藏处理。
针对交易型接口，下单、支付的问题可以提醒用户、为用户推荐同类产品、对产品进行下架或隐藏处理；退票类问题可以建议用户之后重试，如果比较紧急可以联系客服加急处理。
针对通知型接口，不涉及用户，邮件处理即可，可人工介入更新信息。
③产品变动，特别是变价——下单失败率、变价率、出票失败率
Reason：数据更新有时间差。
Solution：
当某一产品的失败率或变价率超出规定，可隐藏或下架；
针对某些产品库存少的情况进行提示，预告风险；
设定合理的定时更新任务。
④下单/支付/退票失败——失败率、失败原因
Reason：用户可能多次提交，或者订单已使用、已关闭等客观原因，无法成功。
Solution：
需要加入检验机制，比如在短时间内重复提交不调用接口，直接返回原结果；
善意提醒用户不要重复提交，如“您的手太快了，请休息30s后再试”；
可以提供IM人工或电话咨询、留言等选项。
⑤服务响应时间长——手工操作订单量和占比
Reason：比如用户提交退票后长时间不退款；支付后长时间不出票
Solution：
定时调用订单查询接口，更新订单状态并短信/推送消息告知用户；
超过服务规范时间前发送预警邮件，人工介入处理。
2.商家体验——数据监控&具体场景
对商家来说，用户体验不重要，转化率和利润才是重点，故数据监控以业务指标为主。
①重复生单、生单不支付占库存——订单量、订单支付转化率、支付失败率、库存占用量和支付量
Reason：用户手速太快；恶意占库存
Solution：制定规则，同一人只能占一个库存；同一订单最多只能订N个人。
②恶意重复调用接口——涉及到的每个接口调用频率
Reason：比如短时间重复调用某一接口
Solution:
规定同一IP地址不能在短时间内多次调用；
直接返回第一次调用接口的结果，不再重复调用；
每个接口在同一时间最多N次调用，否则返回失败等。
③因数据更新不及时等导致的亏损——（佣金、广告）投入产出比、人为损失
Reason：用户使用后退款完成、用户支付后变价等
Solution：根据时间差、处理规则来明确划定责任方。
④结算问题——财务对账自身支出（退款）和收入（美团给商家的结算金额）
Reason：平台和商家以“T+N”的方式结算
Solution：
B端订单系统里的财务对账功能，可以用邮件形式每日发送；
监测异常数据，如当日无结算、结算金额与订单金额不一致。
以上即为接口主要的应用对象和逻辑，逻辑不难但复杂度高，需要细心周到地考虑各种情况，希望能与大家一起讨论。
相关阅读
2014年已经过去，有一大波总结正在靠近。正所谓”举头望明月，低头写总结。洛阳亲友如相问，就说我在写总结。“写年终总结是一个让许多
使用Sina API获取新浪财经的证券股票数据接口(时价 K
从网上找到的Sina API的财经API说，Mark一下，以供以后参考http://market.finance.sina.com.cn/downxls.php?date=2011-07-08&symbol=
今天和大家分享的文章主题是：关于需求管理文档和产品经理的脚手架思维。顾名思义文章分为两个部分：第一部分分享一个重要的需求管理
想到云盘这段经历，最记忆犹新的是，2013年各家网盘血雨腥风的大战；最纠结的是，看似指数级增加的成本数字；最惋惜的是，云盘并不是没有机会
或许对于工作多年的高级运营经理来说，觉得自己升职加薪是理所应当的，毕竟，能成为高级运营经理的人通常都工作几年属于公司老员工，加