共享平台API接口规范文档V0.7s
api 接口方案标准
api 接口方案标准对于API（Application Programming Interface）接口的设计与规范是确保软件系统之间进行有效通信的重要环节。
一个良好的API接口方案能够提升系统的可靠性、可扩展性和互操作性。
本文将分步回答关于API 接口方案标准的问题，为读者提供参考。
第一步：API接口方案的背景和意义API接口是系统之间进行通信的媒介，他们定义了如何请求和响应数据的结构和协议。
良好的API接口方案能够提升开发效率、减少错误和资源消耗，同时也能够提高系统的可维护性和可扩展性。
统一的API接口规范还能够促进不同系统之间的互操作性，降低集成成本和复杂度。
第二步：API接口方案的基本原则一个良好的API接口方案应该遵循以下基本原则：1. 一致性：API接口应该使用统一的命名规范和风格，使得开发者可以迅速理解和使用接口。
2. 简洁性：API接口应该尽量简洁明了，只提供必要的功能和信息，避免不必要的复杂性。
3. 易用性：API接口应该易于使用，提供清晰的文档和示例代码，降低开发者的学习成本。
4. 可扩展性：API接口应该设计为可扩展的，允许在不破坏现有接口的情况下进行功能的扩展和修改。
5. 安全性：API接口应该提供有效的身份验证和授权机制，确保只有合法的用户才能访问敏感数据和功能。
第三步：API接口方案的设计规范一个良好的API接口方案应该遵循以下设计规范：1. 使用标准的协议：API接口应该使用常见的HTTP或HTTPS协议进行通信，并遵循RESTful或SOAP等标准协议的规范。
2. 采用合适的请求方法：API接口应该使用合适的请求方法，如GET、POST、PUT、DELETE等，来进行资源的操作和管理。
3. 使用合适的URL结构：API接口的URL应该采用合适的结构来表示资源和相关操作，如使用名词来表示资源，使用动词来表示操作。
4. 采用合适的数据格式：API接口应该使用标准的数据格式来表示请求和响应的数据，如JSON、XML等。
api接口规则
api接口规则API接口规则是指在进行软件开发或系统集成时，不同系统之间进行数据传递和交互所遵循的一套规范和约定。
API接口规则的设计和使用对于系统的稳定性、可扩展性和安全性具有重要的影响。
本文将介绍一些常见的API接口规则，包括接口命名规范、参数传递规则、错误处理规则等。
一、接口命名规范在设计API接口时，接口的命名应该具有一定的规范性，以便于开发人员的理解和使用。
通常，接口的命名应该采用动词+名词的形式，如getUser、createOrder等。
同时，应该尽量避免使用过长或含糊不清的命名，以免给开发人员带来困扰。
二、参数传递规则在进行API接口调用时，参数的传递是非常重要的。
一般来说，参数的传递可以通过URL、请求头或请求体的形式进行。
对于GET请求，参数通常通过URL的查询字符串进行传递；对于POST请求，参数通常通过请求体进行传递。
在传递参数时，应该明确参数的名称、类型和格式要求，以便于接口的正确调用。
三、返回结果规则API接口的返回结果应该具有一定的规范性，以便于开发人员的理解和处理。
一般来说，返回结果应该包含必要的元数据和数据内容。
元数据包括返回码、错误信息等，用于表示接口调用的状态；数据内容表示接口调用的具体结果。
同时，返回结果的格式应该符合常见的标准，如JSON、XML等。
四、错误处理规则在进行API接口调用时，错误是不可避免的。
因此，对于错误的处理是非常重要的。
一般来说，接口的错误处理应该包括以下几个方面：首先，应该对错误进行分类，以便于开发人员的理解和处理；其次，应该提供清晰的错误信息，以便于开发人员进行定位和修复；最后，应该提供适当的错误码，以便于开发人员进行错误的判断和处理。
五、安全性规则在设计API接口时，安全性是非常重要的一方面。
一般来说，API 接口的安全性可以通过以下几个方面来保障：首先，应该对接口进行身份认证，以确保只有合法的用户才能进行接口调用；其次，应该对接口进行权限控制，以确保只有具有足够权限的用户才能进行敏感操作；最后，应该对接口进行数据加密，以确保数据的传输过程中不被窃取或篡改。
API接口规范
API接⼝规范1. api接⼝应⽤程序编程接⼝（Application Programming Interface，API接⼝），就是应⽤程序对外提供了⼀个操作数据的⼊⼝，这个⼊⼝可以是⼀个函数或类⽅法，也可以是⼀个url地址或者⼀个⽹络地址。
当客户端调⽤这个⼊⼝，应⽤程序则会执⾏对应代码操作，给客户端完成相对应的功能。
当然，api接⼝在⼯作中是⽐较常见的开发内容，有时候，我们会调⽤其他⼈编写的api接⼝，有时候，我们也需要提供api接⼝给其他⼈操作。
由此就会带来⼀个问题，api接⼝往往都是⼀个函数、类⽅法、或者url或其他⽹络地址，不管是哪⼀种，当api接⼝编写过程中，我们都要考虑⼀个问题就是这个接⼝应该怎么编写？接⼝怎么写的更加容易维护和清晰，这就需要⼤家在调⽤或者编写api接⼝的时候要有⼀个明确的编写规范为了在团队内部形成共识、防⽌个⼈习惯差异引起的混乱，我们都需要找到⼀种⼤家都觉得很好的接⼝实现规范，⽽且这种规范能够让后端写的接⼝，⽤途⼀⽬了然，减少客户端和服务端双⽅之间的合作成本。
⽬前市⾯上⼤部分公司开发⼈员使⽤的接⼝实现规范主要有：restful、RPC。
RPC（ Remote Procedure Call ）: 翻译成中⽂:远程过程调⽤[远程服务调⽤]. 从字⾯上理解就是访问/调⽤远程服务端提供的api接⼝。
这种接⼝⼀般以服务或者过程式代码提供。
服务端提供⼀个唯⼀的访问⼊⼝地址：或客户端请求服务端的时候，所有的操作都理解为动作，⼀般web开发时，对应的就是HTTP请求的post请求通过请求体参数，指定要调⽤的接⼝名称和接⼝所需的参数action=get_all_student&class=301&sex=1m=get_all_student&sex=1&age=22command=100&sex=1&age=22接⼝多了,对应函数名和参数就多了,前端在请求api接⼝时难找.容易出现重复的接⼝restful: 翻译成中⽂: 资源状态转换.(表征性状态转移)把服务端提供的所有的数据/⽂件都看成资源，那么通过api接⼝请求数据的操作，本质上来说就是对资源的操作了.因此，restful中要求，我们把当前接⼝对外提供哪种资源进⾏操作，就把资源的名称写在url地址。
api接口文档2篇
api接口文档2篇API接口文档是指对某个API接口的详细说明和规范，可以帮助开发人员快速了解和使用该接口。
本文将介绍两篇关于API接口的文档，涉及接口的功能、请求参数、返回参数等内容。
以下是对两篇API 接口文档的详细描述。
第一篇API接口文档接口名称: 用户登录接口接口功能: 用户通过该接口进行登录操作，获取登录凭证请求URL: /api/login请求方法: POST请求参数:- username (string): 用户名，必填字段- password (string): 密码，必填字段返回参数:- code (int): 返回码，0表示成功，其他值表示失败- message (string): 返回结果信息- token (string): 登录凭证，用于后续请求的身份认证备注: 需要传递参数格式为JSON第二篇API接口文档接口名称: 商品列表接口接口功能: 获取商品列表，支持分页和筛选功能请求URL: /api/products请求方法: GET请求参数:- page (int): 当前页码，默认为1- size (int): 每页显示数量，默认为10- keyword (string): 关键词，模糊搜索商品名称- category (string): 商品分类，筛选商品分类返回参数:- code (int): 返回码，0表示成功，其他值表示失败- message (string): 返回结果信息- data (object): 返回的商品列表数据- id (int): 商品ID- name (string): 商品名称- price (float): 商品价格备注: 无需传递参数时，请求URL为/api/products，参数需要拼接在URL后面，如/api/products?page=2&size=20通过以上对两篇API接口文档的介绍，开发人员可以清楚地了解接口的功能、请求方法、请求参数和返回参数等详细信息。
api共享原则
api共享原则
API（Application Programming Interface）即应用程序编程接口，是一些预先定义的函数，目的是提供应用程序与开发人员基于某软件或硬件得以访问一组例程的能力，而又无需访问源码，或理解内部工作机制的细节。
在设计和使用 API 时，遵循以下共享原则可以提高 API 的质量和可用性：
1. 明确目的：API 的设计应该有明确的目的和用途，能够满足特定的业务需求。
2. 简单易用：API 应该尽可能简单和易于理解，减少开发者的学习成本和使用难度。
3. 稳定性：API 的接口应该保持相对稳定，避免频繁变更，以免影响使用者的应用程序。
4. 向后兼容：在进行 API 更新时，应该尽量保持向后兼容，即保证旧版本的 API 能够在新版本中正常工作。
5. 文档完善：API 需要有详细的文档说明，包括接口定义、参数说明、返回值说明、使用示例等，以便开发者能够正确使用。
6. 错误处理：API 应该提供明确的错误处理机制，以便开发者能够及时处理和恢复错误情况。
7. 安全可靠：API 应该保证数据的安全性和可靠性，避免数据泄露和丢失。
8. 性能优化：API 的设计应该考虑性能优化，尽可能提高接口的响应速度和处理能力。
9. 可扩展性：API 应该具有一定的可扩展性，以便在未来需要时能够方便地进行功能扩展。
10. 社区支持：提供社区支持渠道，以便开发者能够交流和分享经验，及时解决问题。
总之，API 共享原则旨在确保 API 的质量、可用性和可维护性，从而提高开发效率和用户体验。
数据共享一体化交换平台接口规范(个人参考学习版本)
某省智慧大数据接口字典和分类规范1.1.数据字典1.1.1.数据类型1.1.2.信息资源格式分类170304dbf180305dm190306KingbaseEs200307oracle210308sqlserver220309sysbase230310mysql240311GBase250312Hbase260313hdfs270314EsgynDB280315redis290316mongodb300401bmp310402gif320403jpg330501mpg340502rm350503swf360601表格驱动码1.1.3.共享类型1.1.4.共享方式1.1.5.更新周期1.1.6.申请资源类型1.1.7.申请使用范围1.1.8.主题分类88纳税缴费99医疗卫生1010交通旅游1111出境入境1212生活服务1313民族宗教1414三农服务1515死亡殡葬1616设立变更1717行业准营1818投资立项1919工程建设2020涉外服务2121安全生产2222破产注销2323文物保护2424其他1.1.9.参数类型1.1.10.开发类型1.1.11.操作类型12发布20注册31审核43停用54删除65确认删除1.1.12.方法类型1.1.13.协议类型1.1.14.响应类型1.2.返回码1.2.1.通用返回码1.2.2.目录分类1.2.3.目录信息8C-02区共享共享台目录名称长度不符合要求9C-03部门下目录名称已存在10D-01信息资源目录编码不能为空11D-02信息资源目录编码长度不符合要求12D-03信息资源目录编码已存在13E-01统一信用代码不能为空14E-02统一信用代码长度不符合要求15E-03部门不存在16F-01信息资源摘要不能为空17F-02信息资源摘要长度不符合要求18G-01信息资源格式分类编码不能为空19G-02信息资源格式分类编码长度不符合要求20H-01信息资源格式类型编码不能为空21H-02信息资源格式类型编码长度不符合要求22I-01发布日期不能为空23I-02发布日期的日期格式不正确24J-01共享类型编码不能为空25J-02共享类型编码长度不符合要求26K-01共享条件不能为空27K-02共享条件长度不符合要求28L-01共享方式类型编码不能为空29L-02共享方式类型编码长度不符合要求30M-01开放类型不能为空31M-02开放类型长度不符合要求32M-03开放类型必须是整数33N-01开放条件不能为空34N-02开放条件长度不符合要求35O-01更新时间不能为空36O-02更新时间的日期格式不正确37P-01更新周期不能为空38P-02更新周期长度不符合要求39Q-02提供方内部部门长度不符合要求40R-02其他类型资源格式描述长度不符合要求41S-01数据项列表信息不能为空42S-A-02信息项编码长度不符合要求43S-B-01信息项名称不能为空44S-B-02信息项名称长度不符合要求45S-C-01数据类型编码不能为空46S-C-02数据类型编码长度不符合要求47S-D-01数据长度不能为空48S-D-02数据长度的长度不符合要求49S-E-01排序编号不能为空50S-E-02排序编号长度不符合要求51S-F-01更新时间不能为空52S-F-02更新时间的日期格式不正确53Z-01目录未开启接收1.2.4.资源信息34N-D-02参数描述长度不符合要求35O-01返回值数据类型不能为空36O-02返回值数据类型长度不符合要求37P-01响应示例不能为空38P-02响应示例长度不符合要求39Q-01调用示例不能为空40Q-02调用示例长度不符合要求41Z-01资源注册未开启接收42Z-02目录信息不存在43Z-03库表资源未开启接收44Z-04文件资源未开启接收45Z-05接口资源未开启接收1.2.5.申请信息27J-03附件标识长度不符合要求28J-04附件名称长度不符合要求29K-01申请标识不能为空30K-02申请信息不存在31L-01审核意见不能为空32M-01目录标识不能为空33N-01取消资源申请标识不能为空34N-02取消资源申请记录不存在35O-01取消资源申请状态不能为空36O-02"取消资源申请状态输入不规范37Z-01资源申请未开启接收38Z-02下一步处理人不存在39Z-03资源已申请40Z-04发起申请流程失败41Z-05资源取消申请未开启接收42Z-06资源已提交过撤销申请43Z-07发起取消资源申请流程失败44Z-08地自己的目录无需发起申请1.2.6.订阅信息。
接口文档规范
接口文档规范接口文档规范是指在设计和编写接口文档时应遵循的规范和标准。
一个良好的接口文档能够清晰地描述接口的功能、使用方法和参数要求等信息，提供给开发人员使用和集成。
以下是接口文档规范的一些建议和要求：1. 语言清晰简明：接口文档应使用简洁明了的语言描述接口的功能和使用方法，避免使用过于专业术语和复杂的语句，以方便开发人员理解和使用。
2. 接口说明：在接口文档中应包含对接口的功能和作用的详细说明，包括接口的用途、目的和期望的效果等信息。
3. 接口参数：接口文档中应列出接口所需的参数及其类型、说明和取值范围等信息。
对于必须的参数应明确标注其必填属性，对于可选的参数应说明其默认值和是否必填。
4. 接口返回：接口文档中应明确描述接口的返回结果及其类型、说明和可能的取值范围等信息。
对于不同的返回状态码应解释其含义和返回内容。
5. 接口示例：接口文档中应提供接口的使用示例，包括请求参数的示例和返回结果的示例，以方便开发人员理解接口的使用方法和效果。
6. 错误处理：接口文档中应明确描述接口的错误处理方式和可能出现的错误码及其含义。
对于不同的错误码应解释其含义和可能的原因。
7. 接口版本：接口文档中应标明接口的版本号和发布日期，以便开发人员对接口进行版本管理和追踪。
8. 更新记录：接口文档中应包含对接口的更新记录和变更说明，记录每个版本的变更内容和原因，以便开发人员了解接口的演化和调整。
9. 附加说明：接口文档中可以包含一些额外的说明和建议，如安全要求、性能要求、使用限制和注意事项等。
10. 参考资料：接口文档中应提供相关的参考资料和链接，如接口设计文档、数据字典、测试报告等，以便开发人员获取更详细的信息。
以上是接口文档规范的一些基本要素和建议，通过遵循这些规范，可以提高接口文档的可读性和可用性，帮助开发人员更好地理解和使用接口。
同时，良好的接口文档也可以提高团队合作效率，降低沟通成本。
因此，在进行接口开发和集成时，编写清晰规范的接口文档是非常重要的。
api接口规则
API接口规则什么是API接口？API（Application Programming Interface）即应用程序编程接口，是不同软件系统之间进行交互的一种方式。
API接口规则定义了如何使用API进行数据传输和通信。
在网络应用中，API接口规则是实现不同系统之间数据传输和交互的重要规范。
通过遵循API接口规则，不同的应用程序可以相互访问和共享数据，实现功能的互通。
设计原则设计API接口规则需要遵循以下原则：1.一致性：API接口规则应该尽量保持一致，遵循统一的命名规范和数据结构，使得不同的API接口易于理解和使用。
2.简单性：API接口规则应该尽量简单明了，避免过度复杂的设计和冗余的参数，使得开发者可以快速上手并使用API接口。
3.可扩展性：API接口规则应该具备良好的扩展性，能够适应未来的需求变化和技术发展。
设计API接口时应考虑到未来可能的新增功能和数据字段，并提供相应的扩展接口。
4.安全性：API接口规则应该具备一定的安全性，防止未经授权的访问和恶意攻击。
可以通过身份验证、访问令牌等方式来确保API接口的安全性。
基本要素API接口规则包括以下基本要素：1.请求方法：API接口规定了可以使用的请求方法，如GET、POST、PUT等。
不同的请求方法用于执行不同的操作，例如获取数据、创建数据、更新数据等。
2.请求路径：API接口规定了请求的路径，用于定位和访问特定的资源。
请求路径通常由基本路径和路径参数组成，例如/users/{id}，其中{id}为路径参数。
3.请求参数：API接口规定了可以接受的请求参数，用于传递数据和指定操作。
请求参数可以分为路径参数、查询参数和请求体参数。
–路径参数：位于请求路径中的参数，用于指定资源的唯一标识，例如/users/{id}中的{id}。
–查询参数：位于URL中的参数，用于传递额外的信息和条件，例如/users?name=John中的name=John。
- 1、下载文档前请自行甄别文档内容的完整性，平台不提供额外的编辑、内容补充、找答案等附加服务。
- 2、"仅部分预览"的文档,不可在线预览部分如存在完整性等问题,可反馈申请退款(可完整预览的文档不适用该条件!)。
- 3、如文档侵犯您的权益，请联系客服反馈,我们会尽快为您处理(人工客服工作时间：9:00-18:30)。
共享平台API接口规范版本: 0.7s携程旅行网目录1.前言 (4)1.1功能描述 (4)1.2阅读对象 (4)1.3业务术语 (4)1.4技术服务............................................................................................................... 错误!未定义书签。
2.接口参数说明 (5)2.1普通政策请求参数 (5)2.2特惠政策请求参数 (5)2.3特价政策请求参数 (16)3.示例Xml请求 (16)3.1普通政策 (16)3.2特惠政策 (16)3.3特价政策 (19)4.错误代码整理 (21)4.1错误代码规则说明 (21)4.2错误固定标识及错误代码分类说明 (21)4.3目前已知错误代码列表 (21)版本历史1.前言1.1 功能描述为了提高代理商在携程网的政策投放效率，满足其业务需求，由携程机票研发部门开发了一套代理商政策导入接入API。
本文档是为了描述相应的接口规范。
1.2 阅读对象面向具有一定技术实力的代理商公司相应的技术人员1.3 业务术语1.4 接口API导入必读API导入入口：/Flight-Product-TradeAPI/PolicyWS.asmx接口参数：username: 用户名password: 密码（格式: MD5(UTF-8(“username#password”)）)execType: 执行类型，只支持FullADD(全量上传), ADD(增量上传)gzipRequestBytes: 请求报文字节数组，是对报文进行GZIP后产生的字节流接口响应格式：返回的是对报文GZIP后的base64位格式的文本编码目前每日最大请求次数是500次1.5 技术服务前期请直接联系相应的票台关联业务人员2.接口参数说明2.1 普通政策请求参数2.2 特惠政策请求参数2.3 特价政策请求参数暂不提供2.4 返回参数3.示例Xml请求3.1 普通政策<?xml version="1.0"encoding="UTF-8"?><TradePolicyRequest xmlns="urn:ctrip:api:flight:trade:message:PolicyService:v1"> <TradePolicyImportRequest><ExecType>ADD</ExecType><PolicyType>COMMON</PolicyType><PolicyList><Policy><PolicyCode>December</PolicyCode><ProductUnit><EffectDate>2013-12-24T00:00:00</EffectDate><ExpiryDate>2013-12-24T23:59:00</ExpiryDate><ItineraryList><Itinerary><AirlineCode>CA</AirlineCode><DeptAirport>PEK</DeptAirport><ArrvAirport>URC,KWL,WUH,HRB,DLC,SHE</ArrvAirport><FlightEffectDate>2013-12-24T00:00:00</FlightEffectDate><FlightExpiryDate>2013-12-25T00:00:00</FlightExpiryDate><WeekDays>1357</WeekDays><BookingClass>Y,B,L</BookingClass><FlightControl><FlightNumSaleLimitFlag>1</FlightNumSaleLimitFlag><FlightNumRangeList><FlightNumRange><FlightNumStart>5000</FlightNumStart><FlightNumStop>5001</FlightNumStop></FlightNumRange></FlightNumRangeList></FlightControl></Itinerary></ItineraryList></ProductUnit><PriceUnit><ReturnPoint>8</ReturnPoint><ReturnPrice>4</ReturnPrice></PriceUnit></Policy></PolicyList></TradePolicyImportRequest></TradePolicyRequest>3.2 特惠政策请求格式：<?xml version="1.0"encoding="UTF-8"?><TradePolicyRequest xmlns="urn:ctrip:api:flight:trade:message:PolicyService:v1"><TradePolicyImportRequest><ExecType>ADD</ExecType><PolicyType>SPECIAL</PolicyType><PolicyList><Policy><PolicyCode>Inventory</PolicyCode><ProductUnit><ProductType>0</ProductType><EffectDate>2014-01-01T00:00:00</EffectDate><ExpiryDate>2014-01-31T23:59:00</ExpiryDate><MinAdvanceDays>0</MinAdvanceDays><MaxAdvanceDays>365</MaxAdvanceDays><MinStopDays>0</MinStopDays><MaxStopDays>0</MaxStopDays><MinPassengerNum>1</MinPassengerNum><ItineraryList><Itinerary><AirlineCode>MU</AirlineCode><DeptAirport>NKG</DeptAirport><ArrvAirport>PVG</ArrvAirport><FlightEffectDate>2014-01-01T00:00:00</FlightEffectDate><FlightExpiryDate>2014-01-31T00:00:00</FlightExpiryDate><FlightDepartTimeLimitRemarks/><WeekDays>1234567</WeekDays><BookingClass>Y</BookingClass><BookingClassNote/><FlightNo>1989</FlightNo><FlightControl/></Itinerary></ItineraryList><CabinClass>Y</CabinClass><RefundBasis>D</RefundBasis><RefundChangeEndorseRemarks>10-2-20^20-0-50^0</RefundChangeEndorseRemarks> <RefundChangeEndorseNote>for test only</RefundChangeEndorseNote><MinPassengerAge>0</MinPassengerAge><MaxPassengerAge>100</MaxPassengerAge><Remarks/></ProductUnit><PriceUnit><PriceInfo><PrintPrice>0</PrintPrice><SalePrice>880</SalePrice><SetPrice>880</SetPrice></PriceInfo><ReturnPoint>0</ReturnPoint><ReturnPrice>0</ReturnPrice></PriceUnit><InventoryUnit><InventoryType>FIX</InventoryType><SaleableQuantity>5</SaleableQuantity></InventoryUnit><ServiceUnit><OfficeNos/><AutoTicketed>false</AutoTicketed><NeedCreatePNR>true</NeedCreatePNR><NeedChangePNR>true</NeedChangePNR><NeedProvideInvoice>1</NeedProvideInvoice><NeedPata>true</NeedPata><NeedConfirm>false</NeedConfirm><NeedProvideFrequentFlyerScore>false</NeedProvideFrequentFlyerScore><AllowPayDirectly>true</AllowPayDirectly><WorkTimeLimitRemarks>0000-2359,0000-2359,0000-2359,0000-2359,0000-2359,0000-2359,0000-2359</ WorkTimeLimitRemarks><TicketedSpeed>0</TicketedSpeed></ServiceUnit></Policy></PolicyList></TradePolicyImportRequest></TradePolicyRequest>代码示例：ServiceInvokeDemo.7z3.3 特价政策暂不提供3.4 返回结果共有三种返回格式：a. 成功b. 政策错误c. 服务类或者请求错误4.错误代码整理4.1 错误代码规则说明错误代码由三部分组成，两位固定标识+两位错误代码分类+两位业务码+两位错误码4.2 错误固定标识及错误代码分类说明1，2位为固定标识: 803，4位错误代码分类，目前分为以下几类:00: 未知错误01: 请求合法性验证错误(比如销售日期结点不支持输入一个整型值)02: 请求有效性验证错误(比如销售起始日期不能大于其结束日期)03: 业务逻辑类验证错误(比如要求导入一个无效政策)5，6位表示政策类型，可以分为以下几类:00: 特惠政策01: 普通政策02: 特价政策4.3 目前已知错误代码列表注意事项：1、全量上传每次支持100W条政策，增量上传每次支持5W条政策2、全量上传操作后需价格20分钟可以进行下一次操作，增量上传没有间隔时间3、全量上传会覆盖删除接口和excel导入的政策，不会删除手工录入的政策。