智慧公交数字化综合管控平台投标方案（636页）（2024年修订版）.docx

XX市公共交通集团有限公司 目录 第一章 项目建设背景 4 第二章 项目建设目标 5 第三章 总体技术能力 6 第一节 项目设计架构 6 第二节 项目设计原则 17 第三节 项目技术性能 21 第四章 系统建设内容 296 第一节 门户平台 296 第二节 协同平台 307 第三节 预算管理系统 320 第四节 网上报账平台 327 第五节 资金管理系统 339 第六节 智能公交运营管理平台 344 第七节 充电运营管理系统 387 第八节 定制公交管理系统 448 第九节 安全生产管理系统 452 第十节 合同管理系统 464 第十一节 大数据平台 469 第十二节 移动应用 477 第十三节 即时通讯软件 481 第五章 系统安全设计方案 486 第一节 安全需求背景 486 第二节 安全设计思路 488 第三节 安全保障维度 490 第六章 项目实施方案 497 第一节 项目规划管理 503 第二节 项目启动 532 第三节 项目实施进度 535 第四节 系统测试 549 第五节 质量监控管理 572 第六节 保密措施 586 第七节 安全文明施工措施 589 第八节 产品验收标准及流程 592 第七章 项目管理方案 601 第一节 项目范围管理 601 第二节 项目管理制度 602 第三节 实施过程管理 610 第四节 项目质量管理 611 第五节 项目风险管理 615 第八章 项目验收方案 619 第一节 验收对象 619 第二节 项目验收的前提条件 619 第三节 验收步骤 619 第四节 验收内容和标准 620 第五节 验收结论 621 第六节 项目交接 621 第九章 项目培训方案 622 第一节 培训目标 622 第二节 培训内容 623 第三节 培训方式和地点 625 第四节 培训计划 626 第五节 培训管理 627 第六节 培训带队组长 627 第七节 培训费用 628 第十章 项目售后方案 628 第一节 售后支持服务原则与目标 629 第二节 技术支持服务内容和措施 631 第三节 故障排除服务 632 第四节 系统巡检服务 633 第五节 文档提供和更新服务 633 第六节 故障服务流程及标准 635 项目建设背景 城市公共交通是满足人民群众基本出行的社会公益性事业，是基本公共服务的重要组成部分。城市公共交通与人民群众生产生活息息相关，与城市运行和经济发展密不可分，是一项重大的民生工程。大力发展城市公共交通信息化建设，提高公共交通运行、管理效率，为人民群众和社会生活提供更优质、更快捷的出行服务是至关重要的工作，从十一五时期开始，国内公共交通企业已开始建设信息化系统，至十三五时期全国公共交通企业已基本完成智能调度系统、IC卡刷卡系统、车载监控系统等智能化系统的建设和使用。 XX市公共交通集团有限公司XXX年X月X日正式成立，作为XX市政府直属的国有独资公司，承担着XX市的公共交通运营服务，并负责全市公交基础设施投资建设和经营管理，是XX市公共交通业务运营平台。但因信息化系统的分隔、独立，造成了企业无法对汇聚的大量经营生产数据无法统一使用，无法为企业的进一步数字化管理、数字化转型提供有效的支撑。基于国家政策和行业政策要求以及XX公交集团自身数字化转型升级的需求。迫切需要建立一套数据标准统一、接口统一、权限统一，具有综合数据分析、数据应用赋能功能，提升公交系统各业务的智慧公交数字化综合管控平台。 项目建设目标 通过本项目建设，实现对公交系统基础数据的全面采集、可靠传输和充分利用，实现对公交营运的运营调度和运行监管，实现公众出行服务信息的动态生成和及时发布，建立顶层公交监管指挥体系，对各级业务、流程和运营收益进行全面分析，为制定公交行业发展战略提供科学决策依据；全面提高公交业务运营管理、运行监管和科学决策能力，提高公众出行服务水平。 同时在集团信息化总体规划统一指导下，集团将以打造智慧公交数字化综合管控平台为总目标，坚持持续发展的理念，通过开展流程优化、数据梳理、平台搭建、管理提升、数据增值与业务创新，打造一个标准化、一体化、共享化、可视化的数字化管控平台。 标准化：业务体系标准化、系统体系标准化、运维机制标准化、促进XX公交集团管理规范化全面提升。 一体化：通过流程化、自动化，实现各业务部门间的协同效率提升，通过一体化管理提升风险能力。 共享化：通过人、财、物要素资源共享，提升集体资源配置、战略管控能力，结合多维度多层级的管理会计体系，推动资源集约化应用。 可视化：数据共享、纵向贯通，打造XX公交集团可视化综合管控平台，提升智能决策分析、风险预警能力。 总体技术能力 项目设计架构 智慧公交数字化综合管控平台总体结构分为五层：基础设施层、数据支撑层、服务支撑层、业务数据层和用户访问层。 基础设施层提供平台正常运行所需要的软硬件基础，鉴于政府安全管理要求和考虑实际使用场景需要远程访问，本项目支持公有云或者私有云的部署方式。 数据支撑层定义了平台的数据类型、数据库结构、相关规范标准等。平台数据库分为基础数据库、业务数据库两大类。基础数据库为各子业务系统所通用的基础支撑型数据；业务数据库为各子业务系统涉及的专业相关数据。 服务支撑层汇总了平台级的通用服务，如统一身份认证服务、统一支付结算服务等。平台将这些通用的服务统一管理，供各子业务系统进行调用，从而杜绝了各子业务系统的通用功能重复建设，同时助力实现全平台服务体验的一致化。 覆盖前台业务服务、后端数据管控与统计核算，通过模块化设计思路，针对应用层业务，设计和开发相应的功能组件，通过标准接口封装，面向不同应用，进行组件拼接，快速搭建应用系统。本架构不仅可以满足新业务系统的构建，还提供了标准接口协议，满足第三方业务系统的接入。 用户接入层，平台面向最终用户提供服务的终端入口。平台提供PC端+移动端结合的使用方式，方便用户随时随地处理各项业务。具体架构图如下所示： 9.3.2项目技术路线 智慧公交数字化综合管控平台采用微服务架构进行开发，开发语言主要使用JAVA,微服务框架采用SpringCloud,数据库采用Mysql。微服务架构就是将系统划分成非常小的模块，而且这些模块都可以通过一种标准的服务接口进行沟通，每个模块都可以作为一个单独的服务，每个服务可以独立的开发、测试和部署。采用微服务架构，平台灵活性高，并具有高可用性。 (1)技术开发架构设计 数据库使用Mysql作为业务系统的主要数据库 微服务采用SpringCloud作为基础框架，使用前后端分离的开发模式，业务层各个系统由多个微服务组成。 前端选用VWUE.js框架开发 后端主要开发语言为JAVA,支持跨平台移植 采用RESTfulAPI风格的接口设计模式前后端数据交互采用JSON数据格式平台采用统一身份认证和授权的技术方案，使用SpringSecurity和JWT技术实现用户鉴权，平台提供一个统一的入口，支持单点登录，避免各业务系统之间重复登录。 (2)基于SpringBoot和SpringCloud的微服务框架微服务架构优势： 微服务架构是一种架构模式，它提倡将单一应用程序划分成一组小的服务，服务之间互相协调、互相配合，为用户提供最终价值。每个服务运行在其独立的进程中，服务与服务间采用轻量级的通信机制互相沟通(通常是基于HTTP的RESTfulAPI)。每个服务都围绕着具体业务进行构建，并且能够被独立地部署到生产环境、类生产环境等。另外，应尽量避免统一的、集中式的服务管理机制，对具体的一个服务而言，应根据业务上下文，选择合适的语言、工具对其进行构建。 微服务是一种架构风格，一个大型复杂软件应用由一个或多个微服务组成。系统中的各个微服务可被独立部署，各个微服务之间是松耦合的。每个微服务仅关注于完成一件任务并很好地完成该任务。在所有情况下，每个任务代表着一个小的业务能力。 微服务架构具有以下优势： 复杂度可控：在将应用分解的同时，规避了原本复杂度无止境的积累。每一个微服务专注于单一功能，并通过定义良好的接口清晰表述服务边界。由于体积小、复杂度低，每个微服务可由一个小规模开发团队完全掌控，易于保持高可维护性和开发效率。 独立部署：由于微服务具备独立的运行进程，所以每个微服务也可以独立部署。当某个微服务发生变更时无需编译、部署整个应用。由微服务组成的应用相当于具备一系列可并行的发布流程，使得发布更加高效，同时降低对生产环境所造成的风险，最终缩短应用交付周期。 技术选型灵活：微服务架构下，技术选型是去中心化的。每个团队可以根据自身服务的需求和行业发展的现状，自由选择最适合的技术栈。由于每个微服务相对简单，故需要对技术栈进行升级时所面临的风险就较低，甚至完全重构一个微服务也是可行的。 容错：当某一组件发生故障时，在单一进程的传统架构下，故障很有可能在进程内扩散，形成应用全局性的不可用。在微服务架构下，故障会被隔离在单个 服务中。若设计良好，其他服务可通过重试、平稳退化等机制实现应用层面的容错。 扩展：单块架构应用也可以实现横向扩展，就是将整个应用完整的复制到不同的节点。当应用的不同组件在扩展需求上存在差异时，微服务架构便体现出其灵活性，因为每个服务可以根据实际需求独立进行扩展。 SpringBoot框架： 平台采用了SpringBoot和SpingCloud框架实现微服务架构，SpringBoot是一套快速配置脚手架，可以基于SpringBoot快速开发单个微服务；SpringCloud是一个基于SpringBoot实现的服务治理工具包；SpringBoot专注于快速、方便集成的单个微服务个体，SpringCloud关注全局的服务治理框架。 SpringBoot是由Pivotal团队提供的全新框架，其设计目的是用来简化新Spring应用的初始搭建以及开发过程。该框架使用了特定的方式来进行配置，从而使开发人员不再需要定义样板化的配置。 SpringBoot简化了基于Spring的应用开发，通过少量的代码就能创建一个独立的、产品级别的Spring应用。SpringBoot为Spring平台及第三方库提供开箱即用的设置，这样你就可以有条不紊地开始。SpringBoot的核心思想就是约定大于配置，多数SpringBoot应用只需要很少的Spring配置。采用SpringBoot可以大大的简化你的开发模式，所有你想集成的常用框架，它都有对应的组件支持。 SpringCloud框架： SpringCloud是一系列框架的有序集合。它利用SpringBoot的开发便利性巧妙地简化了分布式系统基础设施的开发，如服务发现注册、配置中心、消息总线、负载均衡、断路器、数据监控等，都可以用SpringBoot的开发风格做到—键启动和部署。Spring并没有重复制造轮子，它只是将目前各家公司开发的比较成熟、经得起实际考验的服务框架组合起来，通过SpringBoot风格进行再封装屏蔽掉了复杂的配置和实现原理，最终给开发者留出了一套简单易懂、易部署和易维护的分布式系统开发工具包。 微服务是可以独立部署、水平扩展、独立访问(或者有独立的数据库)的服务单元，SpringCloud就是这些微服务的大管家，采用了微服务这种架构之后，项目的数量会非常多，以下为SpringCloud的核心功能： 分布式/版本化配置服务注册和发现路由服务和服务之间的调用负载均衡断路器分布式消息传递 SpringCloud的组织结构图如下： SpringCloud框架各组件配置使用运行流程： 1、请求统一通过API网关(Zuul)来访问内部服务. 2、网关接收到请求后，从注册中心(Eureka)获取可用服务 3、由Ribbon进行均衡负载后，分发到后端具体实例 4、微服务之间通过Feign进行通信处理业务5、Hystrix负责处理服务超时熔断 6、Turbine监控服务间的调用和熔断相关指标SpringCloud工具框架： 1、SpringCloudConfig配置中心，利用git集中管理程序的配置。2、SpringCloudNetflix集成众多Netflix的开源软件 3、SpringCloudBus消息总线，利用分布式消息将服务和服务实例连接在一起，用于在一个集群中传播状态的变化 4、SpringCloudforCloudFoundry利用PivotalCloudfoundry集成你的应用程序 5、SpringCloudCloudFoundryServiceBroker为建立管理云托管服务的服务代理提供了一个起点。 6、SpringCloudCluster基于Zookeeper,Redis,Hazelcast,Consul实现的领导选举和平民状态模式的抽象和实现。 7、SpringCloudConsul基于HashicorpConsul实现的服务发现和配置管理。 8、SpringCloudSecurity在Zuul代理中为OAuth2rest客户端和认证头转发提供负载均衡 9、SpringCloudSleuthSpringCloud应用的分布式追踪系统，和Zipkin,HTrace,ELK兼容。 10、SpringCloudDataFlow一个云本地程序和操作模型，组成数据微服务在一个结构化的平台上。 11、SpringCloudStream基于Redis,Rabbit,Kafka实现的消息微服务，简单声明模型用以在SpringCloud应用中收发消息。 12、SpringCloudStreamAppStarters基于SpringBoot为外部系统提供spring的集成 13、SpringCloudTask短生命周期的微服务，为SpringBooot应用简单声明添加功能和非功能特性。 14、SpringCloudTaskAppStarters 15、SpringCloudZookeeper服务发现和配置管理基于ApacheZookeeper。16、SpringCloudforAmazonWebServices快速和亚马逊网络服务集成。 17、SpringCloudConnectors便于PaaS应用在各种平台上连接到后端像数据库和消息经纪服务。 18、SpringCloudStarters(项目已经终止并且在Angel.SR2后的版本和其他项目合并) 19、SpringCloudCLI插件用Groovy快速的创建SpringCloud组件应用。RESTfulAPI接口设计： REST指的是一组架构约束条件和原则。满足这些约束条件和原则的应用程序或设计就是RESTful。 早期的网页端是前后台一起的，比如PHP、JSP等。而随着近几年移动端的快速发展和分布式架构的应用，各种Client层出不穷，这个时候就需要有个统一的机制，来为前后端通信提供服务。RESTfulAPI就是目前比较成熟的的一套应用程序API设计理论。 RESTfulAPI的特征和优点如下： 客户端-服务器(Client-Server):提供服务的服务器和使用服务的客户端分离解耦。 优点： 提高客户端的便捷性(操作简单) 简化服务器提高可伸缩性(高性能、低成本)允许客户端服务端分组优化，彼此不受影响 无状态(Stateless):来自客户的每一个请求必须包含服务器处理该请求所需的所有信息(请求信息唯一性); 优点： 提高可见性(可以单独考虑每个请求)提高可靠性(更容易故障恢复) 提高了可扩展性(降低了服务器资源使用) 可缓存(Cachable):服务器必须让客户端知道请求是否可以被缓存?如果可以，客户端可以重用之前的请求信息发送请求； 优点： 减少交互连接数 减少连接过程的网络时延 分层系统(LayeredSystem):允许服务器和客户端之间的中间层(代理， 网关等)代替服务器对客户端的请求进行回应，而客户端不需要关心与它交互的组件之外的事情； 优点： 提高了系统的可扩展性简化了系统的复杂性 统一接口(UniformInterface):客户和服务器之间通信的方法必须是统一化的。(例如：GET,POST,PUT.DELETE) 优点： 提高交互的可见性 鼓励单独优化改善组件 支持按需代码(Code-On-Demand,可选):服务器可以提供一些代码或者脚本并在客户的运行环境中执行。 优点：提高可扩展性VE技术框架： 平台采用VWUE.js作为前端开发使用的技术框架，Vue.js是一个构建数据驱动的web界面的渐进式框架，也是目前市场上主流的前端开发框架。Vue.js的目标是通过尽可能简单的API实现响应的数据绑定和组合的视图组件。WUE.js便于与第三方库或既有项目整合。 VUE.js兼具angular.js和react.js的优点，并剔除了它们的缺点。Vue用于构建交互式的Web界面的库，是一个构建数据驱动的Web界面渐进式框架，该框架遵循CMD规范，并且提供的设计模式为Model->View->View-Model和一个可组合的组合型组件系统，具有简单的、灵活的API。该框架继承了React的虚拟DOM技术和Angular的双向数据绑定技术，是一款较新的功能性框架。 Vue的特性： 轻量级的框架双向数据绑定 指令插件化VUE的优点： 简单：官方文档很清晰，比Angular简单易学。快速：异步批处理方式更新DOM。 组合：用解耦的、可复用的组件组合你的应用程序。紧凑且无依赖。 强大：表达式&无需声明依赖的可推导属性(computedproperties)。 对模块友好：可以通过NPM、Bower或Duo安装，不强迫你所有的代码都遵循Angular的各种规定，使用场景更加灵活。 项目设计原则 智慧公交数字化综合管控平台是集高科技智能化管理、综合化信息展示为一体的信息化平台，整体设计按基础设施先进、设备可靠、系统构架成熟、模块化程度高、接口标准开放，具有高度可扩展性和实用性的原则，能有效控制和提高工作效率，满足业务工作的实际需求，并留有一定的冗余。在先进、可靠和充分满足系统功能的前提下，采用经济实用的技术和设备，并充分利用现有资源，体现高性价比。 平台本着“实用、可靠、先进、经济”的原则，以“规范、高效、节约、透明”为标准，充分利用现有资源，结合XX市的具体情况和实际工作需求进行配置。在技术上扩展升级接口，在系统容量上留有余量，保证平台在较长时间内保持系统的先进性。 (1)可扩展性 作为公共交通的重要机构，XX公交集团提供的服务范畴随着时代的变迁，势必也有扩大和变更的可能性。因此，平台也应当能够随着业务的发展而变化，系统在设计中应充分考虑可扩展性，通过建立标准化信息化体系框架，保证平台具有较大适应性，不会因为业务发展而需要推倒重来。 (2)开放性 基于可扩展性，平台应当具备开放性，主要是指当新的业务或功能加入时，根据既定的框架标准，实现接口即可加入，不需要做过多开发。 满足开闭原则，对外扩展开放，对内修改关闭。采用业界标准的技术规范来设计系统的接口，接口定义符合行业规范，以适应外围系统的更换升级。接口设计支持主流的软硬件平台。 具体体现在：系统支持不同应用系统之间方便地进行数据交换，保证数据的 一致性。系统具备严格的技术和业务规则、合理的业务流程、先进全面的管理手段，以及标准的外部接口。 (3)安全性 安全性与开放性一对动态平衡的原则，过度开放的系统，安全性必然受到挑战。使用足够强度的国际标准加密算法，保证数据不被非法入侵者破坏和盗用，并保证数据的一致性；使用MD5加密，保证数据传输过程不被非法截取。提供数字证书访问认证，支持数字签名。 对欺诈行为采取多种检查和处理手段，提供对系统各模块的监控手段，所有的应用系统运行均产生日志，保证有据可查。 系统中所采用的设备及主要技术必须是成熟的、可靠的，并加以全面的监视和控制，而且充分考虑异常时的应变与容错能力。在应用软件开发中充分利用关系型数据库的安全机制和错误恢复机制，在处理结果未提交前如发生错误则进行回滚，保证数据的准确性和完整性。 数据库设计充分考虑冗余和备份，保证系统数据的安全性、可靠性和数据传输的服务质量。应具有完善的数据备份及恢复机制。 充分利用主机、网络以及数据库管理系统提供的安全保障机制，确保财务数据的绝对安全。不同的操作员授予不同的权限。为了保证数据系统的安全，数据审核、数据审计、定期的安全检查等都是系统所必须的。可以根据业务需要定义数据隔离策略，包括按角色、组织、部门。 (4)易操作、易管理 统一风格的操作界面、完备的帮助信息，系统参数的维护与管理通过操作界面实现；完整的操作流程及操作手册，易于操作人员学习掌握，符合以前系统的操作习惯，避免操作人员学习的重复性。 提供完整的系统管理功能，实现系统的易管理性。系统满足易用性基本需求的五个基本属性： 可学习性(Learnability)使用效率(Efficiency) 可记忆性(Memoryability)少出错率(Errors) 满意程度(Satisfaction) 系统提供良好的出错提示，最大限度的为使用人员提供易于理解的交流方式。 (5)实时性 系统具备实时数据录入或者收集、实时业务处理、实时业务审核、实时后台维护、实时数据统计的功能。对于需要时间进行处理的业务，需要给出用户实时的操作反馈和处理进度信息。 (6)一致性 系统提示信息、界面标签须保持一致的标准。算法相同的计算公式须复用。数据库设计要按照规范化理论进行。为了提高查询效率而设置的冗余数据字段，在修改该字段值时必须保证冗余数据的正确性，而不会因为多个事务并发而发生覆盖错误。确保系统的效率和性能。 整个系统采用统一模型、统一规则、统一资源、统一标准。 项目技术性能 智慧公交数字化综合管控平台采用云原生微服务架构，微服务架构将系统划分成非常小的模块，而且这些模块都可以通过一种标准的服务接口进行沟通，每个模块都可以作为一个单独的服务，每个服务可以独立的开发、测试和部署。采用微服务架构，平台灵活性高，并具有高可用性。在微服务架构下，故障会被隔离在单个服务中。若设计良好，其他服务可通过重试、平稳退化等机制实现应用层面的容错。支持资源弹性伸缩，支持多云部署，提供集系统开发、运行、集成、运维为一体的应用支撑服务，并符合等保二级国家信息安全体系管理要求。硬件资源和网络宽带保证的情况下，参选软件产品必须能够正常、稳定的运行，运行速度要能满足公司日常业务的要求。系统提供性能保障方案，支持在大用户量、高并发业务处理过程中稳定可靠，应用服务器、数据库服务器资源占用正常，系统整体性能表现良好。为保障平台在并发性、稳定性、灵活性方面最大限度的发挥作用，那么整体平台在技术性能设计方面尤其重要，主要在平台数据接口、标准体系及数据库规划方面要体现如下技术能力： 9.3.4.1项目数据接口建设 9.3.4.1.1接口规范设计 平台与外部系统的对接方式以webservice方式进行。本平台API接口采用HTTP/HTTPS(建议HTTPS)作为传输协议。与外部系统对接，通过IP白名单、SSL证书等方式保证集成互访合法性和安全性。 平台子系统众多，通过接口交换的数据与接口调用必须遵循统一的接口模型进行这几。接口模型除了遵循工程统一的数据标准和接口规范标准，实现接口规范定义的功能外，需要从数据管理、完整性管理、接口安全、接口的访问效率、功能以及扩展性等多个方面设计接口规格。 职责原则 在设计接口时，必须明确接口的职责，即接口类型，接口应解决什么业务问题等。 单一性原则 在明确接口职责的条件下，尽量做到接口单一，即一个接口只做一件事，而非两件以上。很多非资深接口设计者，在设计接口时，总认为接口所做的事越多，越牛叉，这是非常严重的错误认识。 协议规范 在设计接口时，应明确接口协议，是采用HTTP协议，HTTPS协议还是FTP协议，要根据具体情况来定。 (1)FTP协议(FileTransferProtocol,简称FTP),是一套标准的文件传输协议，用于传输文件，如.txt,.csv等，一般文件传输，采用FTP协议。 (2)HTTP协议，适用一般对安全性要求比较低或没要求的业务情景。 (3)HTTPS=HTTP+SSL,适用于对安全性要求较高的业务情景。 路径规则 由于api获取的是一种资源，所以网址中尽量为名词，而非动词/api/v1.0/Pruduct/2019 /api/v1.0/Users/2019 http请求方式 接口基本访问协议：get(获取),post(新增),put(修改)和delete(删除)get/users:列出所有用户 get/users/id:根据id获取用户post/user:新增用户 put/user/id:根据用户id更新用户 delete/user/id:根据用户id删除用户 域名 一般地，域名分为主域名和专有域名，主域名适合api长期不变或变化较少的业 务，专有域名是解决具体的专有业务的以百度举例： (1)主域名：www.baidu.com (2)产品服务类 百度文库：https://wenku.baidu.com/百度知道：https://zhidao.baidu.com/百度资讯：https://zhidao.baidu.com/ (3)市场活动类 百度公益：http://gongyi.baidu.com百度logo:http://logo.baidu.com/ 百度世界：https://baidwworld.baidu.com 跨域考虑 在明确域名的情况下，一定要考虑接口是否跨域，以及跨域应采用的技术手段等 api版本 对于接口的url,应加版本号http://api.demo.com/v{d}/,如，其中d表示版本号，如v1.0,v2.0 例子：获取产品号为2019,版本号为v1.0的版本号的产品信息/api/v1.0/Pruducts/2019 适度过滤信息 当记录数比较多时(如SELECT*FROMTBName),因适当添加一些条件对数据进行过滤，如TOP,分页，分组，排序和WHERE条件等 ?limit=100:返回100条数据 ?offset=101:从第101条数据开始返回 per_page=100:每页100条数据 ?sortby=name:排序字段 ?order=desc:降序 ?group=groupName:分组 ?producy_type=1:筛选条件 返回数据格式 返回数据格式，一般包括三个字段： (1)失败情况(状态码、错误码和错误描述) (2)成功情况(标识id,数据对象，状态码) { "sid":"sh20190111",//token id "users":{ "id":"al201901111341",//用户id "name":"Alan_beijing",//用户名 "addr":“用户地址” }, "status":1/ /状态码0-表示失败，1-表示成功 安全性原则 接口暴露的考虑，接口并发量的考虑，接口防攻击的考虑，接口跨域的考虑等。 可扩展性原则 在设计接口时，充分考虑接口的可扩展性。 定义api 界限 任何api, 从权限上，可归结为匿名api和非匿名api, 前者不需要验证，后者 需要验证。 反规范性场景 存在这样一种业务场景：某个接口需要返回多个api接口组合的结果，在类似的业务场景下，所设计的接口，具有一定的反规范性。 假设存在这样一个一个业务：一个ERP系统，需要提供两个接口，一个是用户访问接口(需要验证),另一个是用户注册接口(不需要验证)。 (一)定义统一参数 1、定义统—输入参数 注：注册接口不需要 参数名 类型 是否必须 描述 uide inte Ye 用户ide side stringe Ye 令牌token(session) 2、定义统一输出参数 参数名 类型