电子商务平台API 开放系统设计与实现

麦克尔斯（深圳）科技服务有限公司 索红升

近年来，电子商务行业不断发展，行业竞争更为激烈，同时也有着十分庞大的数据信息和流量。所以相关企业也更加希望通过开放式的系统促进和合作方之间的互利共赢，从而促使相关电商企业正在着手建立专业化的电商平台开放式的API 系统，为外界进行多种多样的服务，从而获取丰富的流量和用户。本文结合电子商务平台API 开放系统的设计方向、系统架构、用户授权、请求鉴权、频率控制以及订购关系这几项主要功能，设计实现了优质的电子商务平台API 开放系统，希望能够借此推动互联网电子商务开放系统良性发展，推动现代化电商企业成长。

1 电子商务平台API 开放系统设计

1.1 系统设计目标

电商API 开放系统与其他开放平台相比，具有明显的电商特性，电商系统当中的商品类型、数量众多，用户包括各种品牌商、卖家、商家、消费者等，用户数量庞大，请求访问异常频繁，另外电商具有复杂的购物流程逻辑，一个订单往往会包括多种不同状态，需要考虑许多问题。总体来看，电商十分复杂，应当在对外开放的同时，在第三方开发者上屏蔽这些复杂的逻辑与流程，因此标准化与通用化是必然的发展方向，外界开发者只需要了解API 接口与相关的参数作用，调用接口能够获取所需信息即可，不再需要掌握电商内部较为复杂的流程与逻辑。电商API 开放系统还属于联系内外的桥梁，发挥着类似于中间件的作用，但这却是一个较为完整的开放系统。内部应当聚合电商业务，外部应当为开发者屏蔽一些业务细节，同时还能够借助于开放系统，促进电商后台的稳定服务，由于API 服务是否稳定取决于电商后台是否稳定，因此在确保后台十分稳定、可靠的前提下，还需要不断优化后台服务可靠并且较为稳定的基础上，应当要求后台进一步优化服务，提升运行效果。外部优势利用API 访问基础服务，此时可能出现超时的情况，这样的问题绝大部分情况下是由基础服务引发的，这时就应当在API 侧推动系统内部改进，从而提高服务整体质量水平。还应当提供内部较为便利的在线文档管理系统，从而奠定系统进一步优化和开发的基础，对业务接口优化与更新过程中的数据信息进行详细记录[1]。

1.2 系统框架

系统设计的整体目标明确之后，可以针对如图1 所示的系统构架图对本文设计实现的开放式API 系统架构全方位的了解，途中展示的主要就是系统基础功能与接口调用流程，与应用的接入以及文档在线测试和开发一类功能没有任何关系，可以让人们更好地了解系统内部流程。在图1 中，右侧的调用人员主要为复杂开发的第三方App，用户们如果订购应用，系统就会直接发送请求，通常需要利用Nhinx 转发至系统当中的服务器内部，由于用户数量较多，因此请求频率会较大，通过转发能够提高系统内部服务器的负载均衡度。利用单一的业务逻辑，在处理之后可以直接进行鉴权与频率监测，同时针对相关用户的请求发出是否正常进行检查，鉴权与频率限制检查主要就是在缓存当中的数据信息进行读取，运用缓存主要就是为了进一步提升检查效率与鉴权性能，定期更新缓存内容，如果出现崩溃，则能够直接对其中数据进行读取，完成鉴权与频率控制。通过鉴权与频率，能够借助于API 接口调取后台业务接口，获取相关信息，而后再将其反馈到调用方。

图1 系统框架图Fig.1 System framework

本开放系统采用开源技术框架的技术容易学习，并且优势众多，开发人员能够在短期内完成开发，其开源技术也有着较为广泛的应用，能够被业内从业人员所接受，外部开发人员也更加熟悉系统架构，更方便系统的开发与应用，满足标准化与通用化的发展目标[2]。

1.3 系统功能设计

1.3.1 用户授权订购关系

用户授权订购关系在电商平台API 开放系统当中属于一个基础，系统后续的相关功能都是服务于这种关系的，该功能的设计能否实现，直接影响系统整体。用户授权订购过程的应用，包括用户、鉴权、登录校验以及授权入口等。电商开放系统当中的用户主要包括买卖双方，第三方开发者所开发的各种应用通常直接挂到电商平台当中，比如在用户完成系统登录之后，就会在管理界面中出现一个专属于第三方的特定工具模块，其主要用来对第三方软件进行展示。移动设备当中大多会设置应用商店，用户们在商店内可以从列表当中挑选App，在某个用户完成对某个App 的订购之后，则应用会针对用户登录情况进行直接检查，如果确认没有登录，则需要用户登录，用户登录之后，应用便会发送授权订购这一请求，询问用户是否需要和应用之间建立一个订购关系。这时就要求电商登录这一模块检查用户的登录状态，在开放系统当中实现。确定所有用户的正常登录状态，在合法申请的基础上，将用户订购关系记录到数据库当中，同时针对订购成功界面进行实时反馈。在此期间，应当进行严格的安全防护，尽可能让所有用户都能够更加便捷的订购应用，完成登录的用户则在进行电极订购并确定之后，便能够快速订购该应用。

1.3.2 请求鉴权

在鉴权环节内，用户首次授权应用会建立订购关系，同时也会获取到访问权限，最开始的流程类似于授权订购流程，鉴权过程中会对用于订购情况开展细致化检查，如果发现订购完成，则直接检查访问权限期限，如果依旧在期限内，则能够请求该系统继续保持运行；如果发现已过期，则可以为用户直接自动续费，一些续期依旧为原理访问Token，但是部分处于安全性可能重新出现多种访问权限。用户们一旦属于首次对应用进行授权，则鉴权应当针对该接口的具体访问权限进行直接调取。在获取访问权限的有效期之后，便会将其直接记录在数据库内，同时用户们自动返回到访问权限。而后用户如果需要调用接口，则可以利用访问权限获取临时权限，利用临时权限生成具体的请求，对Sign 值进行计算，借助于鉴权校验获取信息。鉴权访问接入之后，还应当通过拦截器或过滤器完成检查，这种功能通常是借助于Structs2 实现，两者都能够通过文件的配置从而达到预期工作目的，过滤器则需要依赖于Serlet 容器，拦截器则需要利用Java 落实具体的反射机制。

1.3.3 访问频率控制

当系统接收访问请求后，首先请求会被拦截器拦截，并将其直接输送至检查服务内，首先将用户换粗期间的频率上限数值提取出来，这部分上限数值指的就是用户们在上次访问过程中的次数。得到这个上限值之后，需要进行实时的更新，本质上来说属于上次和本次的两个次数和，同时对缓存当中的用户限制进行更新。该数据能够直接落实到数据库当中，也能够存储在缓存当中，因为其是一种中间数据，所以在达到期限后就能够直接归零而后重新计算，在缓存期间也有可能出现丢失的问题，只需要进行重新计算，将其他所有开销全部落实就可以，因此能够直接保留至缓存当中。更新缓存的数据之后，将数值返回，而后用现阶段的上限数值以及用户访问频率都有着可以对比的受限数据，同时更新对接口部位进行请求的访问次数。用户大部分都存在同样的受限数据，所有的业务接口也拥有总访问受限制。

2 电子商务平台API 开放系统实现

2.1 用户授权订购功能的实现

用户结束应用订购后，一般存在两种差异化情况，首先是用户属于完成过登录状态，此时该应用将请求平台检查用户以往的登录状态，并在得到确认之后，才需要用户进行确认授权，此时还需要结合权限请求用户们的临时权限，在获取之后，才可以继续调用业务接口，并从中得到用户信息；其次是用户属于未登录过的状态，这是就应当返回登录开始界面，等待用户完成授权与登录，继续后续的工作环节。这个过程就是利用UserAuth得以实现，该类当中应用的主要包括应用ID、应用名称、API 接口一类具体的参数信息，用户们在对所订购应用进行授权止呕，主要的操作都是基于Web 网页得以实现，而其中的请求则属于一种十分普遍的协议请求。在授权期间，具体流程是通过UserAuth 类内部的Auth方法得以实现的。

2.2 请求鉴权功能的实现

请求鉴权主要有3 种，本文分析的就是用户授权当中的内部鉴权这种功能。请求鉴权这个工作属于利用拦截器得以实现的，在接入请求后，首先会受到拦截器直接拦截，完成检查工作，在检查结束后继续完成后续操作。鉴权工作就是用作对操作的操作人员进行验证，其中涉及到的需要检查的主要包括UID、AppID、Skey 以及权限一类参数信息，还有业务接口内请求参数，这些都可以利用计算Sign 数值进行检查。Sign 值计算过程中最为关键的一个步骤就是对参数进行拼接，获取原本的计算字符串，比如用户们在调用接口完成发布信息的工作期间，商品参数就能够直接简化，变成itemCode。

2.3 访问频率控制功能的实现

访问频率控制主要就是借助于拦截器完成的，实现的主要类有Limit Interceptor，实际判断逻辑主要借助于API UID Frequence 得以实现。针对访问频率进行控制就是要统计用户们在5min 内的具体访问次数，明确是否存在超额问题。首先会获取缓存内部数据信息，针对用户们在规定时间内是否会出现5min 访问的情况进行判断，如果超过，则应当重新对访问次数与时间进行计算。如果在有效期内，则应当判断这一阶段内的访问次数与规定频率之间是否相符，一旦超出则应当针对用户们的特殊权限与特殊规则进行继续判断，特殊用户则能够继续进行访问，但也可以直接上报，如果用户不是特殊类型的用户，则应当对其访问进行限制。如果缓存当中没有数据，则需要新增技术与计时，并将其更新在缓存当中。

2.4 系统实现流程

2.4.1 系统管理员用例

开放系统内部操作最频繁的一个人员就属于管理人员，通常分为应用管理、访问频率管理与业务接口管理三方面。其中应用管理包括以下内容：（1）查询检索应用。所有应用都应当在系统当中注册，集中展示到系统当中，更便于管理员随时检查和具体应用；（2）查看详细的应用信息。管理人员可以随时获取应用所有信息和功能，比如其中的开发者数据信息、访问Token 以及应用权限等；（3）审核应用与测试。所有应用在系统推向用户之前，都应当通过开发自测与系统检测，确保其没有任何不良导向之后才能够推向所有用户；（4）卸载应用。应用废气或合作完成之后，管理人员可以将应用直接卸载。

业务接口管理主要包括以下用例：（1）新增接口鉴权信息。开放系统当中的业务接口主要可以划分为三大类，即访问公共信息类、访问用户信息类以及设计用户隐私与商业信息类；（2）接口修改鉴权信息。管理人员可以随时针对业务接口内部鉴权信息进行查看，同时也可以随时修改；（3）查询接口列表。业务接口都可以结合电商流程在不同的模块内完成分类，比如常见的订单接口与商品杰阔等，而管理人员则可以针对不同模块内的接口列表进行查询；（4）查询接口内部信息。业务接口内部信息较为丰富，管理员能够随时查看所有接口当中的所有信息。

2.4.2 第三方开发者用例

负责开发的第三方主要用例可分为以下几点：（1）服务商的注册。第三方的所有开发者既能够是个人、企业，也可以是团队，在开发者们开发调用接口过程中，首先需要在系统内部将自己注册变成服务商，也就是以合作者的身份进行开发。通常可以进行个人与企业两种不同的服务商注册；（2）申请应用开通权限。开发者可以在完成注册后，便第一时间申请开通，完成开通后则可以获取ID、访问权限以及数字签名，而后便能够开发应用；（3）查看应用。第三方开发者通常可以开发多种应用，特别是类似于企业与团队开发人员，他们能够随时对应用列表与信息进行查看，比如开通应用期间必备的3 个主要参数；（4）应用信息的完整编辑。针对自行开发的应用，开发人员还能够编辑系统内部基础信息，明确具体的开发进度、应用功能以及开发设置等；（5）管理应用。在结束应用开发后，就应当推出用户应用，需要利用管理人员审核才能够正式推出应用，所以要求开发人员需要进行直接的审核申请，其中包括测试申请审核的应用，还有上下架以及升级等具体内容。

3 结语

综上所述，在当前的大数据背景下，电子商务平台API 开放系统的科学设计与实现，能够有效推动网络大数据技术的合理应用，使其更好地服务于电商行业，促进电商行业的现代化、先进化、高效化发展。