CN113467780A - 一种数据获取方法、装置、电子设备及存储介质 - Google Patents

Abstract

本公开关于一种数据获取方法、装置、电子设备及存储介质，包括：本申请实施例发送目标应用需求对应的数据请求；数据请求中包含有目标应用需求对应的标识信息，将数据请求发送至目标应用需求对应的位于客户端的目标服务层；目标服务层是基于控制器信息和接口信息生成的；控制器信息和接口信息是服务器基于接收到的接口文档请求反馈的，利用目标服务层获取标识信息对应的返回数据的模拟数据。本公开实施例中，客户端直接根据控制器信息和接口信息生成目标服务层，减少服务器和客户端的沟通成本，同时可以基于返回数据的模拟数据保证服务器和客户端的并行开发，提高开发效率。

Description

一种数据获取方法、装置、电子设备及存储介质

技术领域

本公开涉及互联网技术领域，尤其涉及一种数据获取方法、装置、电子设备及存储介质。

背景技术

目前，应用的组件模型的管理是整个应用中较为重要的一部分。对于应用的组件模型，主要由两部分组成：一部分是前端基于数据进行的渲染状态，主要由前端主导维护；另一部分是后端的业务模型，主要由后端负责，具体的，后端会封装各种满足架构约束条件和原则的应用程序的服务层给前端调用获取。基于上述描述，可以看出数据使用者和维护者角色是不同的，这种情况下，就会存在比较大的沟通成本。

与此同时，在业务项目中，前端的开发需依赖后端数据，如果在项目的开发过程中前端需要等到后端接口开发完成后才开始串行的开发，可能会影响整个项目的效率。

发明内容

本公开提供一种数据获取方法、装置、电子设备及存储介质，本公开的技术方案如下：

根据本公开实施例的第一方面，提供一种数据获取方法，包括：

发送目标应用需求对应的数据请求；数据请求中包含有目标应用需求对应的标识信息；

将数据请求发送至目标应用需求对应的位于客户端的目标服务层；目标服务层是基于控制器信息和接口信息生成的；控制器信息和接口信息是服务器基于接收到的接口文档请求反馈的；

利用目标服务层获取标识信息对应的返回数据的模拟数据。

在一些可能的实施例中，方法还包括：

向服务器发送接口文档请求；接口文档请求中包含接口地址；

接收服务器反馈的基于接口地址获取的接口文档；

对接口文档进行解析，得到控制器信息以及控制器信息对应的接口信息；

确定目标应用需求对应的控制器信息和接口信息；

基于目标应用需求对应的控制器信息和接口信息生成目标服务层。

在一些可能的实施例中，方法还包括：

从接口信息中确定接口出参信息；

利用目标服务层基于接口出参信息生成返回数据的模拟数据。

在一些可能的实施例中，方法还包括：

接收服务器发送的文档更新指令；

向服务器发送接口文档请求；接口文档请求中包含接口地址；

接收服务器反馈的基于接口地址获取的更新后的接口文档。

在一些可能的实施例中，利用目标服务层基于接口出参信息生成返回数据的模拟数据包括：

利用目标服务层基于接口出参信息中的类型信息生成返回数据的模拟数据。

在一些可能的实施例中，将数据请求发送至目标应用需求对应的目标服务层包括：

利用中间件模块获取数据请求；

将数据请求转发至目标应用需求对应的目标服务层。

根据本公开实施例的第二方面，提供一种数据获取装置，包括：

数据请求发送模块，被配置为执行发送目标应用需求对应的数据请求；数据请求中包含有目标应用需求对应的标识信息；

数据请求转发模块，被配置为执行将数据请求发送至目标应用需求对应的位于客户端的目标服务层；目标服务层是基于控制器信息和接口信息生成的；控制器信息和接口信息是服务器基于接收到的接口文档请求反馈的；

模拟数据获取模块，被配置为执行利用目标服务层获取标识信息对应的返回数据的模拟数据。

在一些可能的实施例中，装置还包括：

接口文档请求发送模块，被配置为执行向服务器发送接口文档请求；接口文档请求中包含接口地址；

接口文档接收模块，被配置为执行接收服务器反馈的基于接口地址获取的接口文档；

文档解析模块，被配置为执行对接口文档进行解析，得到控制器信息以及控制器信息对应的接口信息；

信息确定模块，被配置为执行确定目标应用需求对应的控制器信息和接口信息；

服务层生成模块，被配置为执行基于目标应用需求对应的控制器信息和接口信息生成目标服务层。

在一些可能的实施例中，装置还包括：

接口出参信息确定模块，被配置为执行从接口信息中确定接口出参信息；

模拟数据生成模块，被配置为执行利用目标服务层基于接口出参信息生成返回数据的模拟数据。

在一些可能的实施例中，装置还包括更新指令接收模块：

更新指令接收模块，被配置为执行接收服务器发送的文档更新指令；

接口文档请求发送模块，被配置为执行向服务器发送接口文档请求；接口文档请求中包含接口地址；

接口文档接收模块，被配置为执行接收服务器反馈的基于接口地址获取的更新后的接口文档。

在一些可能的实施例中，模拟数据生成模块，被配置为执行：利用目标服务层基于接口出参信息中的类型信息生成返回数据的模拟数据。

在一些可能的实施例中，数据请求转发模块，包括：

中转模块，被配置为执行利用中间件模块获取数据请求；

数据请求转发子模块，被配置为执行将数据请求转发至目标应用需求对应的目标服务层。

根据本公开实施例的第三方面，提供一种电子设备，包括：处理器；用于存储处理器可执行指令的存储器；其中，处理器被配置为执行指令，以实现如上述第一方面中任一项的方法。

根据本公开实施例的第四方面，提供一种计算机可读存储介质，当计算机可读存储介质中的指令由电子设备的处理器执行时，使得电子设备能够执行本公开实施例的第一方面中任一项的方法。

根据本公开实施例的第五方面，提供一种计算机程序产品，计算机程序产品包括计算机程序，计算机程序存储在可读存储介质中，计算机设备的至少一个处理器从可读存储介质读取并执行计算机程序，使得计算机设备执行本公开实施例的第一方面中任一项的方法。

本公开的实施例提供的技术方案至少带来以下有益效果：

本申请实施例发送目标应用需求对应的数据请求；数据请求中包含有目标应用需求对应的标识信息，将数据请求发送至目标应用需求对应的位于客户端的目标服务层；目标服务层是基于控制器信息和接口信息生成的；控制器信息和接口信息是服务器基于接收到的接口文档请求反馈的，利用目标服务层获取标识信息对应的返回数据的模拟数据。本公开实施例中，客户端直接根据控制器信息和接口信息生成目标服务层，减少服务器和客户端的沟通成本，同时可以基于返回数据的模拟数据保证服务器和客户端的并行开发，提高开发效率。

应当理解的是，以上的一般描述和后文的细节描述仅是示例性和解释性的，并不能限制本公开。

附图说明

此处的附图被并入说明书中并构成本说明书的一部分，示出了符合本公开的实施例，并与说明书一起用于解释本公开的原理，并不构成对本公开的不当限定。

图1是根据一示例性实施例示出的一种应用环境的示意图；

图2是根据一示例性实施例示出的一种数据获取方法的流程图；

图3是根据一示例性实施例示出的一种服务层生成方法的流程图；

图4是根据一示例性实施例示出的一种模拟数据生成方法的流程图；

图5是根据一示例性实施例示出的一种当前接口文档更新方法的流程图；

图6是根据一示例性实施例示出的一种数据获取设备的框架图；

图7是根据一示例性实施例示出的一种数据获取装置的框图；

图8是根据一示例性实施例示出的一种用于数据获取的电子设备的框图。

具体实施方式

为了使本领域普通人员更好地理解本公开的技术方案，下面将结合附图，对本公开实施例中的技术方案进行清楚、完整地描述。

需要说明的是，本公开的说明书和权利要求书及上述附图中的术语“第一”、“第二”等是用于区别类似的第一对象，而不必用于描述特定的顺序或先后次序。应该理解这样使用的数据在适当情况下可以互换，以便这里描述的本公开的实施例能够以除了在这里图示或描述的那些以外的顺序实施。以下示例性实施例中所描述的实施方式并不代表与本公开相一致的所有实施方式。相反，它们仅是与如所附权利要求书中所详述的、本公开的一些方面相一致的装置和方法的例子。

本公开所涉及的数据可以为经用户授权或者经过各方充分授权的数据。

请参阅图1，图1是根据一示例性实施例示出的一种数据获取方法的应用环境的示意图，如图1所示，该应用环境可以包括服务器01和客户端02。

在一些可能的实施例中，服务器01可以是接收到客户端02发送的接口文档请求后，基于接口文档请求中包含的后端接口地址反馈给客户端02当前接口文档的服务器。可选的，服务器可以包括是独立的物理服务器，也可以是多个物理服务器构成的服务器集群或者分布式系统，还可以是提供云服务、云数据库、云计算、云函数、云存储、网络服务、云通信、中间件服务、域名服务、安全服务、CDN(Content Delivery Network，内容分发网络)、以及大数据和人工智能平台等基础云计算服务的云服务器。

在一些可能的实施例中，上述的客户端02发送目标应用需求对应的数据请求，数据请求中包含有目标应用需求对应的标识信息，将数据请求发送至目标应用需求对应的位于客户端的目标服务层；目标服务层是基于控制器信息和接口信息生成的；控制器信息和接口信息是服务器基于接收到的接口文档请求反馈的，利用目标服务层获取标识信息对应的返回数据的模拟数据。其中，上述的客户端可以包括但不限于智能手机、台式计算机、平板电脑、笔记本电脑、智能音箱、数字助理、增强现实(augmented reality，AR)/虚拟现实(virtual reality，VR)设备、智能可穿戴设备等类型的设备。也可以为运行于上述设备的软体，例如应用程序、小程序等。可选的，设备上运行的操作系统可以包括但不限于安卓系统、IOS系统、linux、windows、Unix等。

在一些可能的实施例中，客户端02和服务器01之间可以通过有线链路连接，也可以通过无线链路连接。

图2是根据一示例性实施例示出的一种数据获取方法的流程图，如图2所示，数据获取方法可以应用于客户端，也可以应用于其他节点，包括以下步骤：

在步骤S201中，发送目标应用需求对应的数据请求；数据请求中包含有目标应用需求对应的标识信息。

本公开实施例中，执行上述步骤S201的发送目标应用需求对应的数据请求的客户端可以是前后端架构中的前端设备。由于本申请的目标之一是客户端可以直接根据控制器信息和接口信息生成目标服务层，以减少服务器和客户端的沟通成本，提高开发效率，同时可以基于返回数据的模拟数据保证服务器和客户端的并行开发，因此，该前端设备可以是前端开发人员所使用的设备。由此可以得到，当客户端是前端开发人员的设备时，其发送的目标应用需求对应的数据请求是给后端开发人员所使用的设备的，比如后端开发人员的终端或者服务器。下面为了便于阐述，将以客户端和服务器来分别指代两侧设备。

本公开实施例中，上面的目标应用需求可以是任何一个需求，比如可以是在客户端上的某个网页中的组件开发需求，在客户端上的某个应用程序中的组件测试需求等等。其中，上面的组件可以是某个网页中的表格，对话框，按钮等等。具体地，可以是对某个组件进行操作后，返回的是用户信息或者用户链表等等。

本公开实施例中，为了达到客户端(前端客户端)和服务器(后端服务器)可以并行开发或者测试，而不是等待服务器(后端服务器)将所有的接口开发完，客户端(前端客户端)才能基于接口进行开发，或者，服务器(后端服务器)将所需测试的组件测试完毕，客户端(前端客户端)才能基于该组件进行进一步地测试。客户端(前端客户端)可以在发送目标应用需求对应的数据请求，用于获得最终的返回数据的模拟数据之前，可以先基于服务器(后端服务器)提供的当前接口文档在客户端(前端客户端)的本地服务中建立虚拟服务器，从而使得客户端和服务器，也就是前端客户端和后端服务器可以并行开发或者测试。

图3是根据一示例性实施例示出的一种服务层生成方法的流程图，如图3所示，包括以下步骤：

步骤S2001中：向服务器发送接口文档请求；接口文档请求中包含接口地址。

本公开实施例中，客户端可以向服务器发送接口文档请求，该接口文档请求中可以包含有接口地址。可选的，上述的接口文档请求可以是一个基于HTTP协议的请求。

可选的，上述的接口地址可以是服务器，也就是后端服务器提供的，因此，接口地址也可以被称为后端接口地址。

在一些可能的实施例中，该接口地址可以是一个访问路径。服务器将定义的接口打包好，生成接口文档之后，可以将接口文档存储在服务器的某个存储空间内，并基于该服务器的接口文档存储的存储空间生成访问路径，以使得客户端可以基于该访问路径访问接口文档。

在一些可选的实施例中，该接口地址，即访问路径是不会变的，也就是说，无论是服务器第一次生成接口文档，还是定义的接口，可能在后续会有一些更新，需要基于更新后定义的接口重新打包生成接口文档，并将重新打包生成的接口文档存储在上述固定的存储空间。基于上述情况，客户端在基于接口地址获取接口文档时，只需要基于客户端和服务器约定好的接口地址直接获取就行，最终得到定义的接口的更新不会过多的影响到客户端的有益效果。

本公开实施例中，接口文档可以包括服务器(后端服务器)定义的所有接口，还可以是后端服务器定义的部分接口。具体包含哪些接口可以根据当前客户端的应用需求来决定。

举个例子，假设客户端对后端服务器的应用需求主要是获取一张带有某些参数的表格信息。某些参数可以包括A信息，B信息和C信息。可选的，服务器可以根据上述内容确定3个参数对应的3个接口对象(A信息对应的接口1，B信息对应的接口2和C信息对应的接口3)。可选的，可能因为这3个参数的紧密性，存在被不同应用需求复用的可能，因此，服务器可以将这3个参数定义为一个接口对象，这个接口对象里面包括3个参数。可选的，基于带有某些参数的表格信息对应的接口文档请求中包含的后端接口地址可以被表示为“/rest/userinform”。

步骤S2002中：接收服务器反馈的基于接口地址获取的接口文档。

基于上述例子继续阐述，本公开实施例中，当服务器接收到接口文档请求后，可以从该接口文档请求中解析得到后端接口地址“/rest/userinform”，基于该后端接口地址“/rest/userinform”从存储空间中找到接口文档，并将接口文档发送给客户端。对应的，客户端可以接收服务器反馈的基于接口地址获取的接口文档。

在一些可能的实施例中，该当前接口文档是一个JSON类型的数据。

步骤S2003中：对接口文档进行解析，得到多个控制器信息以及控制器信息对应的接口信息。

本公开实施例中，客户端可以对接口文档进行解析，得到多个控制器信息以及每个控制器信息对应的接口信息，如果按照上述例子，每个参数对应一个接口对象，则A信息可以对应控制器信息1和接口信息1，B信息可以对应控制器信息2和接口信息2，以及C信息可以对应控制器信息3和接口信息3。

在一些可能的实施例中，每一个接口信息可以包括该接口信息对应的接口的接口标识信息，接口入参信息和接口出参信息。

步骤S2004中：确定目标应用需求对应的控制器信息和接口信息。

本公开实施例中，由于客户端在进行开发或者测试任务时，存在不同的应用需求，因此，客户端可以先确定每个应用需求对应的控制器信息和接口信息，也就是说，客户端可以根据数据组装的形式确定不同的控制器信息和接口信息，进而可以基于确定的控制器信息和接口信息为后续生成不同的服务层做准备。

若步骤S2004中目标应用需求就是获取一张带有某些参数的表格信息中的参数，则从当前接口信息中确定的就是控制器信息1，接口信息1，控制器信息2，接口信息2，控制器信息3和接口信息3。

步骤S2005中：基于目标应用需求对应的控制器信息和接口信息生成目标服务层。

本公开实施例中，由于上述步骤已经确定出目标应用需求对应的控制器信息和接口信息，客户端就可以直接根据目标应用需求对应的控制器信息和接口信息(接口标识信息，接口入参信息和接口出参信息)生成目标服务层，也就是生成代表目标服务层的代码。

可选的，上述例子中只是以目标应用需求为例进行的阐述，至于其他应用需求如何确定控制器信息和接口信息，再基于确定的控制器信息和接口信息生成对应的服务层，请参考上述目标应用需求的内容，这里将不再赘述。

如此，本公开实施例通过服务器提供的接口文档直接生成目标服务层，由于服务层的代码与接口文档的数据是一致的，如果接口文档的数据发生改变，则服务层的代码就会改变，如此，在本申请的实施例中，可以减少客户端和服务器的沟通成本，提高开发效率。

图4是根据一示例性实施例示出的一种模拟数据生成方法的流程图，如图4所示，在图3的基础上，可以包括以下步骤：

步骤2006中，从接口信息中确定出接口出参信息。

在一些可能的实施例中，由于返回数据的模拟数据是上述内容涉及到的在客户端中的虚拟服务器返回给客户端的，且由于虚拟服务器中的返回数据的模拟数据在实际的服务器中就是接口出参数据，因此，只要从接口信息中确定出接口出参数据，就可以为生成返回数据的模拟数据做准备了。

步骤S2007中，利用目标服务层基于接口出参信息生成返回数据的模拟数据。

本申请实施例中，客户端还可以获取接口信息中的接口出参信息，并基于该接口出参信息生成返回数据的模拟数据。

在一个可选的实施例中，客户端可以根据接口出参信息生成该目标应用需求的返回数据的模拟数据，并将返回数据的模拟数据存储在构建的一个文件夹中，并生成该文件夹对应的标识信息。可选的，该标识信息在生成后，可以和目标应用需求、目标服务层建立联系，当发送目标应用需求对应的数据请求，数据请求中的标识信息就是上述文件夹对应的标识信息，该标识信息可以使得客户端定位到目标服务层，然后目标服务层可以取出文件夹中的返回数据的模拟数据返回给客户端。

可选的，上述的标识信息可以是一个统一资源定位器(Uniform ResourceLocator,URL)信息。

如此，使得前端开发或者测试人员在服务器没有开发完毕的基础上，可以不考虑服务器对客户端的影响，直接利用返回数据的模拟数据进行开发应用，让客户端和服务器可以并行的开发，提高开发效率。

在一些可选的实施例中，生成的目标服务层包括基于Typescript脚本语言生成的服务层或者基于Javascript脚本语言生成的服务层。若生成的目标服务层包括基于Typescript脚本语言生成的服务层，则客户端可以基于接口出参信息中的类型信息生成返回数据的模拟数据，其中，上述类型信息包括浮点型，整型。

如此，本公开实施例可以针对不同类型的客户端或者不同的开发人员提供不同脚本语言，使得本公开实施例的技术方法更有使用性，更容易被推广。

上文已经提到，服务器可以在第一次生成接口文档，也可以因为定义的接口在后续会有一些更新，需要基于更新后定义的接口重新打包生成接口文档。那么，如果定义的接口后续出现一些更新，在导致需要基于更新后定义的接口重新打包生成接口文档的情况下，客户端还在使用之前的当前接口设备生成的服务层或者返回数据的模拟数据进行开发或者测试，必然会导致客户端和服务器的数据使用的不一致。为了解决上述的问题，本公开实施例提供一种当前接口文档在客户端中的更新方法。

图5是根据一示例性实施例示出的一种当前接口文档更新方法的流程图，如图5所示，可以包括以下步骤：

在步骤S501中，接收服务器发送的文档更新指令。

本公开实施例中，当服务器检测到定义的接口发生改变时，比如将某个接口入参数据由“信息A”改变成“信息A+”,又增加了一个接口入参数据“信息A++”时，可以基于更新后定义的接口重新打包生成接口文档，并用更新后的接口文档替换之前的接口文档。

在一些可能的实施例中，当服务器确定更新后的接口文档已经替换之前的接口文档后，可以向客户端发送一个文档更新指令，该文档更新指令可以告知客户端接口文档已经发生改变，需要重新去获取。

在步骤S503中，向服务器发送接口文档请求；接口文档请求中包含接口地址。

在步骤S505中，接收服务器反馈的基于接口地址获取的更新后的接口文档。

本公开实施例中，步骤S503-S505中的实施方式具体参考S2001-S2002步骤的内容，这里不再赘述，且在得到更新后的接口文档后，客户端可以根据步骤S2003-S2006生成更新后的目标服务层和更新后的返回数据的模拟数据。

在步骤S203中，客户端将数据请求发送至目标应用需求对应的位于客户端的目标服务层；目标服务层是基于控制器信息和接口信息生成的，控制器信息和接口信息是服务器基于接收到的接口文档请求反馈的。

在一些可能的实施例中，前端的客户端在发送目标应用需求对应的数据请求给后端的服务器的时候，可以自主的将该数据请求发送至目标应用需求对应的位于客户端的目标服务层。

在一些可能的实施例中，客户端在在发送目标应用需求对应的数据请求给后端的服务器的时候，可以利用中间件模块截取数据请求，并通过该中间件模块将数据请求发送至目标应用需求对应的目标服务层。

本申请实施例中，当客户端能够使用本申请的数据获取方式时，安装有该方法对应的配置或者说装置，该配置可以提供一个中间件模块。这是因为当生成目标服务层后，该目标服务层对于目标应用需求来说，就是一个替代后端的虚拟后端(虚拟服务器)，由于前端客户端和后端服务器是同步开发的，本方案在实际应用过程中，可以将数据请求发送至前端客户端创建的虚拟服务器，因此，需设置一个中间件模块进行数据请求的中转，实现将数据请求发送至前端客户端。

本申请实施例中，由于上文已经提到，接口请求中的标识信息是和目标服务层以及对应的文件夹有映射关系的，因此，当中间件接收到数据请求后，可以从该数据请求中得到标识信息，通过标识信息定位到目标服务层，由此，可以将接口请求发送至目标应用需求对应的目标服务层。

在步骤S205中，利用目标服务层获取标识信息对应的返回数据的模拟数据。

在一个可选的实施例中，客户端可以利用目标服务层获取标识信息对应的接口入参信息和返回数据的模拟数据。在此实施例中，标识信息，比如URL信息中包括接口入参信息，比如“信息A＝XXXX”,但是目标服务器并不会URL信息进行解析，只会通过目标服务器从文件夹里取出接口入参信息和返回数据的模拟数据，比如“信息A＝XXXX,信息B＝YYYY”,其中，“信息A＝XXXX”为接口入参信息，“信息B＝YYYY”是返回数据的模拟数据。当然还可以是“信息A＝XXXXX,信息B＝YYYYY”,也就是说，不一定要根据URL信息中的接口入参信息得到对应的返回数据的模拟数据。因为这里为客户端的应用需求，要目标服务器反馈的返回数据的模拟数据是正常的数据就满足要求了。

图6是根据一示例性实施例示出的一种数据获取设备的框架图，下面结合上文的实施例对图6所示的数据获取设备的框架图进行阐述。可选的，客户端向服务器发送接口文档请求，接口文档请求中包括服务器给予客户端的接口地址。客户端基于该接口地址访问到存储在服务器某个存储空间中的接口文档，即图6左侧的接口文档，其中，接口文档中可以包括控制器信息和接口信息(接口标识信息，接口入参信息和接口出参信息)，其中，模型参数可以是包含有各种接口标识信息，接口入参信息和接口出参信息的集合，模型参数可以为客户端所需的每个应用需求提供不同的接口信息。此外，接口文档还可以包括访问路径。

在图6的中间部分显示的是，服务器可以根据接口文档利用代码生成器生成对应不同应用需求的服务层。其中，服务器可以基于第一脚本语言生成服务层或者基于第二脚本语言生成的服务层，第一脚本语言和第二脚本语言都可以基于自定义生成模板(引用，模块之间的调用等等)进行处理。具体的，第一脚本语言需要结合定义好的类型和接口层代码生成服务层，可选的，第一脚本语言可以是Typescript脚本语言。第二脚本语言通过在接口层代码的基础上生成服务层，可选的，第二脚本语言可以是Javascript脚本语言。Typescript脚本语言和Javascript脚本语言只是本申请实施例中可选的两种脚本语言，在实际的应用过程中，其他的脚本语言也是可以的。

在图6的右侧部分显示的是，当客户端接收到中间件模块截取的数据请求后，可以利用目标服务层获取标识信息对应的返回数据的模拟数据，并通过服务模拟的中间层返回至客户端。如此，中间部分和右侧部分就组成了客户端获取返回数据的模拟数据的整个过程。

综上，本申请实施例中，客户端在发送目标应用需求对应的数据请求，用于获得最终的返回数据的模拟数据之前，可以先基于后端提供的当前接口文档在客户端的本地服务中建立虚拟服务器，从而使得前后端可以并行开发或者测试。同时，通过可能存在的更新后定义的接口重新打包生成当前接口文档，避免客户端还在使用之前的当前接口设备生成的服务层或者返回数据的模拟数据进行开发或者测试，使得前端和后端数据使用保持一致。

图7是根据一示例性实施例示出的一种数据获取装置框图。参照图7，该装置包括数据请求发送模块701、数据请求转发模块702和模拟数据获取模块703。

数据请求发送模块701，被配置为执行发送目标应用需求对应的数据请求；数据请求中包含有目标应用需求对应的标识信息；

数据请求转发模块702，被配置为执行将数据请求发送至目标应用需求对应的位于客户端的目标服务层；目标服务层是基于控制器信息和接口信息生成的；控制器信息和接口信息是服务器基于接收到的接口文档请求反馈的；

模拟数据获取模块703，被配置为执行利用目标服务层获取标识信息对应的返回数据的模拟数据。

在一些可能的实施例中，装置还包括：

接口文档请求发送模块，被配置为执行向服务器发送接口文档请求；接口文档请求中包含接口地址；

接口文档接收模块，被配置为执行接收服务器反馈的基于接口地址获取的接口文档；

文档解析模块，被配置为执行对接口文档进行解析，得到控制器信息以及控制器信息对应的接口信息；

信息确定模块，被配置为执行确定目标应用需求对应的控制器信息和接口信息；

服务层生成模块，被配置为执行基于目标应用需求对应的控制器信息和接口信息生成目标服务层。

在一些可能的实施例中，装置还包括：

接口出参信息确定模块，被配置为执行从接口信息中确定接口出参信息；

模拟数据生成模块，被配置为执行利用目标服务层基于接口出参信息生成返回数据的模拟数据。

在一些可能的实施例中，装置还包括更新指令接收模块：

更新指令接收模块，被配置为执行接收服务器发送的文档更新指令；

接口文档请求发送模块，被配置为执行向服务器发送接口文档请求；接口文档请求中包含接口地址；

接口文档接收模块，被配置为执行接收服务器反馈的基于接口地址获取的更新后的接口文档。

在一些可能的实施例中，模拟数据生成模块，被配置为执行：利用目标服务层基于接口出参信息中的类型信息生成返回数据的模拟数据。

在一些可能的实施例中，数据请求转发模块，包括：

中转模块，被配置为执行利用中间件模块获取数据请求；

数据请求转发子模块，被配置为执行将数据请求转发至目标应用需求对应的目标服务层。

关于上述实施例中的装置，其中各个模块执行操作的具体方式已经在有关该方法的实施例中进行了详细描述，此处将不做详细阐述说明。

图8是根据一示例性实施例示出的一种用于数据获取的电子设备800的框图。

该电子设备可以是服务器，还可以是终端设备，其内部结构图可以如图8所示。该电子设备包括通过系统总线连接的处理器、存储器和网络接口。其中，该电子设备的处理器用于提供计算和控制能力。该电子设备的存储器包括非易失性存储介质、内存储器。该非易失性存储介质存储有操作系统和计算机程序。该内存储器为非易失性存储介质中的操作系统和计算机程序的运行提供环境。该电子设备的网络接口用于与外部的终端通过网络连接通信。该计算机程序被处理器执行时以实现一种数据获取方法。

本领域技术人员可以理解，图8中示出的结构，仅仅是与本公开方案相关的部分结构的框图，并不构成对本公开方案所应用于其上的电子设备的限定，具体的电子设备可以包括比图中所示更多或更少的部件，或者组合某些部件，或者具有不同的部件布置。

在示例性实施例中，还提供了一种电子设备，包括：处理器；用于存储该处理器可执行指令的存储器；其中，该处理器被配置为执行该指令，以实现如本公开实施例中的数据获取方法。

在示例性实施例中，还提供了一种计算机可读存储介质，当该计算机可读存储介质中的指令由电子设备的处理器执行时，使得电子设备能够执行本公开实施例中的数据获取方法。

在示例性实施例中，还提供了一种计算机程序产品，计算机程序产品包括计算机程序，计算机程序存储在可读存储介质中，计算机设备的至少一个处理器从可读存储介质读取并执行计算机程序，使得计算机设备执行本公开实施例的数据获取方法。

本领域普通技术人员可以理解实现上述实施例方法中的全部或部分流程，是可以通过计算机程序来指令相关的硬件来完成，该计算机程序可存储于一非易失性计算机可读取存储介质中，该计算机程序在执行时，可包括如上述各方法的实施例的流程。其中，本申请所提供的各实施例中所使用的对存储器、存储、数据库或其它介质的任何引用，均可包括非易失性和/或易失性存储器。非易失性存储器可包括只读存储器(ROM)、可编程ROM(PROM)、电可编程ROM(EPROM)、电可擦除可编程ROM(EEPROM)或闪存。易失性存储器可包括随机存取存储器(RAM)或者外部高速缓冲存储器。作为说明而非局限，RAM以多种形式可得，诸如静态RAM(SRAM)、动态RAM(DRAM)、同步DRAM(SDRAM)、双数据率SDRAM(DDRSDRAM)、增强型SDRAM(ESDRAM)、同步链路(Synchlink)DRAM(SLDRAM)、存储器总线(Rambus)直接RAM(RDRAM)、直接存储器总线动态RAM(DRDRAM)、以及存储器总线动态RAM(RDRAM)等。

本领域技术人员在考虑说明书及实践这里公开的发明后，将容易想到本公开的其它实施方案。本申请旨在涵盖本公开的任何变型、用途或者适应性变化，这些变型、用途或者适应性变化遵循本公开的一般性原理并包括本公开未公开的本技术领域中的公知常识或惯用技术手段。说明书和实施例仅被视为示例性的，本公开的真正范围和精神由下面的权利要求指出。

应当理解的是，本公开并不局限于上面已经描述并在附图中示出的精确结构，并且可以在不脱离其范围进行各种修改和改变。本公开的范围仅由所附的权利要求来限制。

Claims (10)

1.一种数据获取方法，其特征在于，包括：

发送目标应用需求对应的数据请求；所述数据请求中包含有所述目标应用需求对应的标识信息；

将所述数据请求发送至所述目标应用需求对应的位于客户端的目标服务层；所述目标服务层是基于控制器信息和接口信息生成的；所述控制器信息和所述接口信息是服务器基于接收到的接口文档请求反馈的；

利用所述目标服务层获取所述标识信息对应的返回数据的模拟数据。

2.根据权利要求1所述的数据获取方法，其特征在于，所述方法还包括：

向所述服务器发送所述接口文档请求；所述接口文档请求中包含接口地址；

接收所述服务器反馈的基于所述接口地址获取的接口文档；

对所述接口文档进行解析，得到控制器信息以及所述控制器信息对应的接口信息；

确定所述目标应用需求对应的控制器信息和接口信息；

基于所述目标应用需求对应的控制器信息和接口信息生成所述目标服务层。

3.根据权利要求2所述的数据获取方法，其特征在于，所述方法还包括：

从所述接口信息中确定接口出参信息；

利用所述目标服务层基于所述接口出参信息生成所述返回数据的模拟数据。

4.根据权利要求2所述的数据获取方法，其特征在于，所述方法还包括：

接收所述服务器发送的文档更新指令；

向所述服务器发送所述接口文档请求；所述接口文档请求中包含所述接口地址；

接收所述服务器反馈的基于所述接口地址获取的更新后的接口文档。

5.根据权利要求3所述的数据获取方法，其特征在于，所述利用所述目标服务层基于所述接口出参信息生成所述返回数据的模拟数据包括：

利用所述目标服务层基于所述接口出参信息中的类型信息生成所述返回数据的模拟数据。

6.根据权利要求1所述的数据获取方法，其特征在于，所述将所述数据请求发送至所述目标应用需求对应的目标服务层包括：

利用中间件模块获取所述数据请求；

将所述数据请求转发至所述目标应用需求对应的目标服务层。

7.一种数据获取装置，其特征在于，包括：

数据请求发送模块，被配置为执行发送目标应用需求对应的数据请求；所述数据请求中包含有所述目标应用需求对应的标识信息；

数据请求转发模块，被配置为执行将所述数据请求发送至所述目标应用需求对应的位于客户端的目标服务层；所述目标服务层是基于控制器信息和接口信息生成的；所述控制器信息和所述接口信息是服务器基于接收到的接口文档请求反馈的；

模拟数据获取模块，被配置为执行利用所述目标服务层获取所述标识信息对应的返回数据的模拟数据。

8.一种电子设备，其特征在于，包括：

处理器；

用于存储所述处理器可执行指令的存储器；

其中，所述处理器被配置为执行所述指令，以实现如权利要求1至6中任一项所述的数据获取方法。

9.一种计算机可读存储介质，其特征在于，当所述计算机可读存储介质中的指令由电子设备的处理器执行时，使得所述电子设备能够执行如权利要求1至6中任一项所述的数据获取方法。

10.一种计算机程序产品，其特征在于，所述计算机程序产品包括计算机程序，所述计算机程序存储在可读存储介质中，计算机设备的至少一个处理器从所述可读存储介质读取并执行所述计算机程序，使得所述计算机设备执行如权利要求1至6中任一项所述的数据获取方法。

Images