WO2025124161A1 - 一种基于fetch优化前端数据交互的方法、系统和终端 - Google Patents

一种基于fetch优化前端数据交互的方法、系统和终端 Download PDF

Info

Publication number
WO2025124161A1
WO2025124161A1 PCT/CN2024/135496 CN2024135496W WO2025124161A1 WO 2025124161 A1 WO2025124161 A1 WO 2025124161A1 CN 2024135496 W CN2024135496 W CN 2024135496W WO 2025124161 A1 WO2025124161 A1 WO 2025124161A1
Authority
WO
WIPO (PCT)
Prior art keywords
request
response
data
fetch
cache
Prior art date
Legal status (The legal status is an assumption and is not a legal conclusion. Google has not performed a legal analysis and makes no representation as to the accuracy of the status listed.)
Pending
Application number
PCT/CN2024/135496
Other languages
English (en)
French (fr)
Inventor
刘桥
纪烁
王汕
张�杰
黄创光
Current Assignee (The listed assignees may be inaccurate. Google has not performed a legal analysis and makes no representation or warranty as to the accuracy of the list.)
China Telecom Cloud Technology Co Ltd
Original Assignee
China Telecom Cloud Technology Co Ltd
Priority date (The priority date is an assumption and is not a legal conclusion. Google has not performed a legal analysis and makes no representation as to the accuracy of the date listed.)
Filing date
Publication date
Application filed by China Telecom Cloud Technology Co Ltd filed Critical China Telecom Cloud Technology Co Ltd
Publication of WO2025124161A1 publication Critical patent/WO2025124161A1/zh
Anticipated expiration legal-status Critical
Pending legal-status Critical Current

Links

Classifications

    • G—PHYSICS
    • G06—COMPUTING OR CALCULATING; COUNTING
    • G06F—ELECTRIC DIGITAL DATA PROCESSING
    • G06F16/00—Information retrieval; Database structures therefor; File system structures therefor
    • G06F16/90—Details of database functions independent of the retrieved data types
    • G06F16/95—Retrieval from the web
    • G06F16/958—Organisation or management of web site content, e.g. publishing, maintaining pages or automatic linking
    • G—PHYSICS
    • G06—COMPUTING OR CALCULATING; COUNTING
    • G06F—ELECTRIC DIGITAL DATA PROCESSING
    • G06F16/00—Information retrieval; Database structures therefor; File system structures therefor
    • G06F16/90—Details of database functions independent of the retrieved data types
    • G06F16/95—Retrieval from the web
    • G06F16/955—Retrieval from the web using information identifiers, e.g. uniform resource locators [URL]
    • G—PHYSICS
    • G06—COMPUTING OR CALCULATING; COUNTING
    • G06F—ELECTRIC DIGITAL DATA PROCESSING
    • G06F16/00—Information retrieval; Database structures therefor; File system structures therefor
    • G06F16/90—Details of database functions independent of the retrieved data types
    • G06F16/95—Retrieval from the web
    • G06F16/957—Browsing optimisation, e.g. caching or content distillation
    • G06F16/9574—Browsing optimisation, e.g. caching or content distillation of access to content, e.g. by caching

Definitions

  • the present application belongs to the technical field of Web program development, and specifically relates to a method, system and terminal for optimizing front-end data interaction based on fetch.
  • Ajax which stands for "Asynchronous Javascript And XML" refers to a web development technology for creating interactive and dynamic web applications. It can asynchronously update part of the web page content without reloading the entire web page.
  • the purpose of this application is to provide a method, system and terminal for optimizing front-end data interaction based on fetch, which can solve the technical problems of single function and difficult code maintenance and use in traditional technologies.
  • a method for optimizing front-end data interaction based on fetch comprising:
  • the web page configuration includes global configuration and local configuration
  • the local configuration overrides the global configuration
  • the configuration parameters include cache switch, request path prefix, URL encoding, request method, request header, response parsing settings, request parameter data structure, common parameters, timeout period, and standard response success status code;
  • response success status code to be evaluated is consistent with the standard response success status code, processing the corresponding response data according to the state of the cache switch;
  • the server data is requested and the server data is saved in the local storage.
  • the request path prefix is used to store the common path of the request
  • the common parameters are used to store the common parameters in the request
  • the request parameter data structure supports URL, FORM form, and JSON structure to be submitted to the server to adapt to the server data requirements.
  • the business layer before sending the fetch request to the server, if there is a request interceptor for verifying the validity of the parameters, the business layer passes the request URL and request parameters to the request interceptor array, and the fetch request will not be issued until all the request interceptors are executed. Otherwise, the fetch request is generated directly.
  • a timeout listener for monitoring the data response duration is turned on, and after the data response returns with a timeout, the listener code is executed, and subsequent responses are canceled, and the timeout error is reported to the business layer. Conversely, if the data response returns without a timeout, the listener code execution is canceled and a fetch request is generated.
  • the server status and network status are collected in real time;
  • server status or network status is abnormal, a server error is thrown to the business layer and the subsequent process is terminated. Otherwise, the server obtains the data and indicates that the fetch request response is successful.
  • the steps after the fetch request response is successful include:
  • the step of processing corresponding response data according to the state of the cache switch includes:
  • the present application also provides a system for optimizing front-end data interaction based on fetch, which is applied to the above-mentioned method for optimizing front-end data interaction based on fetch, and the system includes:
  • a configuration module the configuration module is used to obtain a web page configuration and its corresponding configuration parameters, wherein the web page configuration includes a global configuration and a local configuration, the local configuration overrides the global configuration, and the configuration parameters include a cache switch, a request path prefix, a URL encoding, a request method, a request header, a response parsing setting, a data structure of request parameters, common parameters, a timeout period, and a standard response success status code;
  • a request module which is used to obtain business requirements and request methods of the business requirements, turn on the switch of wrapping data in the body, merge the body.data object into the body, and delete the original body.data object;
  • a calling module which is used to turn on the cache switch, query whether there is cache data corresponding to the business demand in the local cache, and directly call the cache data if there is cache data in the local cache, otherwise, send a fetch request to the server;
  • a response module the response module is used to obtain response data corresponding to the fetch request from the server, and synchronously generate a response success status code to be evaluated, and then compare the response success status code to be evaluated with a standard response success status code;
  • response success status code to be evaluated is consistent with the standard response success status code, processing the corresponding response data according to the state of the cache switch;
  • a terminal for optimizing front-end data interaction based on fetch comprising:
  • the memory stores a computer program executable by the at least one processor, and the computer program is executed by the at least one processor so that the at least one processor can execute the above-mentioned method for optimizing front-end data interaction based on fetch.
  • This application is different from the traditional xhr-based data interaction method. It adopts native fetch technology. While meeting the data interaction, it provides advanced customized settings such as custom timeout, cache settings, request interceptor, response interceptor, request header, response parsing settings, and exception standardization processing, enriching the data request process and forming full-process support for business scenarios. At the same time, the underlying layer of this method naturally supports Promise. Compared with traditional technologies, there is no callback hell, and it has better performance, easy access and maintainability. It has more advantages than other traditional data request methods in meeting multiple business scenarios and using docking.
  • FIG1 is a flowchart of fetch request generation provided by the present application.
  • FIG. 2 is a response flow chart of a fetch request provided in this application.
  • one embodiment or “embodiment” as used herein refers to a specific feature, structure or characteristic that may be included in at least one implementation of the present application.
  • the phrase "in a preferred embodiment” that appears in different places in this specification does not refer to the same embodiment, nor is it a separate or selective embodiment that is mutually exclusive with other embodiments.
  • the present application provides a method for optimizing front-end data interaction based on fetch, including:
  • the response success status code to be evaluated is consistent with the standard response success status code, the corresponding response data is processed according to the state of the cache switch;
  • Fetch API is a modern network request API that provides a global fetch() method that can be used to obtain resources.
  • the design goal of Fetch API is to provide a simple, reasonable, and controllable way to handle network requests, allowing developers to focus more on data processing and business logic.
  • the global configuration and local configuration are first extracted from the given web page configuration.
  • the global configuration involves the macro settings of the entire web page, while the local configuration is more specific, covering the detailed configuration of a specific area.
  • These configuration parameters include cache switch, request path prefix, URL encoding, request method, request header, response parsing settings, request parameter data structure, common parameters, timeout period and standard response success status code, which provide detailed information for the server and business layer to understand and process the web page configuration.
  • the server will pay special attention to the request method and turn on the switch that wraps the data in the body.
  • This step is to merge the body.data pair.
  • the image is added to the body and the original body.data object is deleted.
  • This processing makes the data more centralized and concise, which is convenient for subsequent data processing and analysis.
  • the business layer will query whether there is cache data corresponding to the business needs in the local cache. If it exists, the business layer will directly call the cache data. If not, it will send a fetch request to the server. This design effectively reduces unnecessary network requests and improves efficiency.
  • After obtaining the response data corresponding to the fetch request from the server it will synchronously generate a response success status code to be evaluated. Then, it will compare this response success status code to be evaluated with the standard response success status code. If the two are consistent, the corresponding response data will be processed according to the status of the cache switch. If the two are inconsistent, the request will be interrupted and an error report will be generated. This processing method ensures the accuracy and consistency of the data.
  • the server data is requested and saved in the local storage.
  • a query is first made in the local cache to determine whether there is cache data corresponding to the business demand, thereby reducing the generation of unnecessary network requests.
  • the request path prefix is used to store the common path of the request
  • the common parameters are used to store the common parameters in the request
  • the request parameter data structure supports URL, FORM form, and JSON structure submitted to the server to adapt to the server data requirements.
  • the business layer before sending a fetch request to the server, if there is a request interceptor for verifying the validity of parameters, the business layer passes the request URL and request parameters to the request interceptor array, and the fetch request is not issued until all request interceptors are executed. Otherwise, a fetch request is generated directly.
  • the business layer will pass the request URL and request parameters to the request interceptor array, and each request interceptor will verify the request parameters to ensure the validity of the parameters. Only when all request interceptors are executed and the validity of the parameters is ensured, will the fetch request be actually issued. On the contrary, if there is no request interceptor for verifying the validity of parameters, the business layer will directly generate a fetch request without waiting for any additional verification steps. Such a design can ensure the timeliness and efficiency of the request and avoid unnecessary waiting time.
  • a timeout listener for monitoring the duration of a data response is enabled, and after the data response returns a timeout, the listener code is executed, and subsequent responses are canceled, and a timeout error is reported to the business layer. Conversely, if the data response returns without a timeout, the listener code execution is canceled, and a fetch request is generated.
  • the timeout listener is enabled. Once the data response time exceeds the predetermined threshold, the device will trigger the execution of the preset code and cancel the subsequent response in time to avoid unnecessary resource consumption. At the same time, the device will report the timeout error to the business layer so that the business layer can understand and handle the problem in time. If the data response time does not exceed the predetermined threshold, the timeout listener will remain silent and wait for the next data response task, providing strong data protection for the business layer.
  • the server status and network status will be collected in real time
  • server status or network status is abnormal, a server error is thrown to the business layer and the subsequent process is terminated. Otherwise, the server obtains the data and indicates that the fetch request response is successful.
  • the steps after the fetch request response is successful include:
  • the response data is first parsed according to the configuration information of the web page, and a response interceptor is set.
  • This interceptor starts running after the server passes the request URL and response data. It passes these data to the response interceptor array for subsequent processing. Then, if the response interceptor returns an error, the execution of all subsequent programs will be terminated immediately, and the interceptor error will be thrown to the business layer, so that the business layer can quickly understand and handle the problem. Finally, if all response interceptors are executed and no error is returned, a response success status code to be evaluated will be generated synchronously. This status code can be used to determine whether the request is successful and how the response data should be processed after success. In this way, we can ensure that all steps are executed correctly and the response data can be processed effectively after the request is successful.
  • the step of processing corresponding response data according to the state of the cache switch includes:
  • the cache switch is set for the local cache, that is, after the cache switch is turned on, the server response data can be added to the local cache to facilitate direct calls by the subsequent business layer.
  • the response data in the local cache can be set according to the user's needs or according to the call frequency. The purpose is to speed up data response and reduce unnecessary network requests.
  • the present application also provides a system for optimizing front-end data interaction based on fetch, which is applied to the above-mentioned method for optimizing front-end data interaction based on fetch, and the system includes:
  • the configuration module is used to obtain web page configuration and its corresponding configuration parameters, wherein the web page configuration includes global configuration and local configuration, the local configuration overrides the global configuration, and the configuration parameters include cache switch, request path prefix, URL encoding, request method, request header, response parsing settings, request parameter data structure, common parameters, timeout period and standard response success status code;
  • the request module is used to obtain business requirements and request methods of business requirements, turn on the switch of wrapping data in the body, merge the body.data object into the body, and delete the original body.data object;
  • the calling module is used to turn on the cache switch and query whether there is cache data corresponding to the business needs in the local cache. If there is cache data in the local cache, the cache data is directly called. Otherwise, a fetch request is sent to the server.
  • the response module is used to obtain the response data corresponding to the fetch request from the server, and synchronously generate the response success status code to be evaluated, and then compare the response success status code to be evaluated with the standard response success status code;
  • the response success status code to be evaluated is consistent with the standard response success status code, the corresponding response data is processed according to the state of the cache switch;
  • the system when the system is executed, it first obtains the configuration information and parameters of the web page through the configuration module, then obtains the business requirements through the request module, turns on the switch that includes data in the request body, merges the body.data object into the request body, and deletes the original body.data object. Then, the calling module is used to query whether there is cache data corresponding to the business requirements in the local cache. If it exists, the cache data is used directly; if it does not exist, a fetch request is sent to the server, and finally the corresponding module is executed to respond to the fetch request and output the corresponding response data.
  • a terminal for optimizing front-end data interaction based on fetch comprising:
  • the memory stores a computer program that can be executed by at least one processor, and the computer program is executed by at least one processor so that the at least one processor can execute the above-mentioned method for optimizing front-end data interaction based on fetch.

Landscapes

  • Engineering & Computer Science (AREA)
  • Databases & Information Systems (AREA)
  • Theoretical Computer Science (AREA)
  • Data Mining & Analysis (AREA)
  • Physics & Mathematics (AREA)
  • General Engineering & Computer Science (AREA)
  • General Physics & Mathematics (AREA)
  • Information Retrieval, Db Structures And Fs Structures Therefor (AREA)

Abstract

本申请属于Web程序开发技术领域，具体涉及一种基于fetch优化前端数据交互的方法、系统和终端。本申请有别于传统的基于xhr的数据交互方法，采用基于原生的fetch技术，在满足数据交互的同时，提供了自定义超时时间、缓存设置、请求/响应拦截器、请求头/响应解析设置、错误/异常标准化处理等高级定制化设置，丰富了数据请求过程，形成了业务场景全流程支持，同时，该方法底层天然支持Promise，和传统技术比，不存在回调地狱，拥有更好的性能、易接入和可维护性，在满足多业务场景和使用对接方面，比传统的其他数据请求方法更有优势。

Description

一种基于fetch优化前端数据交互的方法、系统和终端
相关申请的交叉引用
本申请要求在2023年12月13日提交中国专利局、申请号为202311712625.6、发明名称为“一种基于fetch优化前端数据交互的方法”的中国专利申请的优先权，其全部内容通过引用结合在本申请中。
技术领域
本申请属于Web程序开发技术领域，具体涉及一种基于fetch优化前端数据交互的方法、系统和终端。
 背景技术
Ajax即“Asynchronous Javascript And XML”(异步JavaScript和XML)，是指一种创建交互式、动态网页应用的网页开发技术，无需重新加载整个网页的情况下，能够异步更新部分网页内容的技术。
与传统表单式的技术模式相比，显著提高了用户的响应，也节省了服务端带宽、资源等开销，所以越来越多产品使用了Ajax技术构建富应用(Rich internet Application)。
在传统的Ajax技术中，以xhr(XMLHTTPRequest)为核心，通过提前注册事件回调，响应服务端发送的数据，完成数据通信。同时，存在以下问题：
1.功能单一，仅仅完成一次数据交互，对于交互过程中产生的异常/错误难以捕捉；
2.缺乏超时、拦截、缓存等功能，难以满足日常开发需求；
3.通过注册事件回调，容易引起回调嵌套(“回调地狱”)，给调试、维护带来困难，增加了代码复杂度
4、基于此封装的框架，后期不易于维护，想要支持自定义新功能比较困难。
 发明内容
本申请的目的是提供一种基于fetch优化前端数据交互的方法、系统和终端，能够解决传统技术中功能单一、代码不易维护和使用的技术问题。
本申请采取的技术方案具体如下：
一种基于fetch优化前端数据交互的方法，包括：
获取网页配置以及其对应的配置参数，其中，所述网页配置包括全局配置和局域配置，所述局域配置覆盖全局配置，所述配置参数包括缓存开关、请求路径前缀、URL编码、请求方法、请求头、响应解析设置、请求参数的数据结构、公共参数、超时时间以及标准响应成功状态码；
获取业务需求，并获取所述业务需求的请求方法，且开启body中包裹data的开关，再合并body.data对象到body中，并删除原有body.data对象；
开启缓存开关，查询本地缓存中是否存在与业务需求对应的缓存数据，且在本地缓存内存在缓存数据时，直接调用该缓存数据，反之，则向服务端发送fetch请求；
从所述服务端获取与fetch请求对应的响应数据，且同步生成待评估响应成功状态码，再将所述待评估响应成功状态码与标准响应成功状态码进行比对；
若所述待评估响应成功状态码与标准响应成功状态码一致，则根据缓存开关的状态处理对应的响应数据；
若所述待评估响应成功状态码与标准响应成功状态码不一致，则中断请求，并生成错误报告。
在一种可选方案中，所述缓存开关首次开启时，请求服务端数据，并将所述服务端数据保存至本地存储中。
在一种可选方案中，所述请求路径前缀用于存放请求的共有路径，所述公共参数用于存放请求中共有的参数，所述请求参数数据结构支持URL、FORM表单、JSON结构提交到服务端，适配服务端数据需求。
在一种可选方案中，所述向服务端发送fetch请求之前，若存在用于验证参数有效性的请求拦截器，则业务层传递请求url和请求参数到请求拦截器数组，待所有所述请求拦截器执行完毕后才会发出fetch请求，反之，则直接生成fetch请求。
在一种可选方案中，所述业务需求生成后，开启用于监听数据响应时长的超时监听器，且在所述数据响应返回超时后，则执行监听器代码，并取消后续响应，再报告超时错误给业务层，反之，若数据响应返回未超时，则取消监听器代码执行，并生成fetch请求。
在一种可选方案中，所述fetch请求向服务端发送后，实时采集服务器状态以及网络状态；
若所述服务器状态或网络状态异常，则抛出服务器错误给业务层，并终止后续流程，反之，则服务端获取到数据，并表明fetch请求响应成功。
在一种可选方案中，所述fetch请求响应成功后的步骤，包括：
根据网页配置解析响应数据，并设置响应拦截器，且服务端传递请求url和响应数据到响应拦截器数组；
若所述响应拦截器返回错误，则终止后续所有程序执行，并抛出拦截器错误给业务层；
若所有响应拦截器执行完毕，且未返回错误，则同步生成待评估响应成功状态码。
在一种可选方案中，所述根据缓存开关的状态处理对应的响应数据的步骤，包括：
获取缓存开关的状态，判断其是否开启；
若所述缓存开关开启，则将该响应数据添加至本地存储中；
若所述缓存开关关闭，则直接筛除该响应数据。
本申请还提供了，一种基于fetch优化前端数据交互的系统，应用于上述的基于fetch优化前端数据交互的方法，所述系统包括：
配置模块，所述配置模块用于获取网页配置以及其对应的配置参数，其中，所述网页配置包括全局配置和局域配置，所述局域配置覆盖全局配置，所述配置参数包括缓存开关、请求路径前缀、URL编码、请求方法、请求头、响应解析设置、请求参数的数据结构、公共参数、超时时间以及标准响应成功状态码；
请求模块，所述请求模块用于获取业务需求，并获取所述业务需求的请求方法，且开启body中包裹data的开关，再合并body.data对象到body中，并删除原有body.data对象；
调用模块，所述调用模块用于开启缓存开关，查询本地缓存中是否存在与业务需求对应的缓存数据，且在本地缓存内存在缓存数据时，直接调用该缓存数据，反之，则向服务端发送fetch请求；
响应模块，所述响应模块用于从所述服务端获取与fetch请求对应的响应数据，且同步生成待评估响应成功状态码，再将所述待评估响应成功状态码与标准响应成功状态码进行比对；
若所述待评估响应成功状态码与标准响应成功状态码一致，则根据缓存开关的状态处理对应的响应数据；
若所述待评估响应成功状态码与标准响应成功状态码不一致，则中断请求，并生成错误报告。
以及，一种基于fetch优化前端数据交互的终端，包括：
至少一个处理器；
以及与所述至少一个处理器通信连接的存储器；
其中，所述存储器存储有可被所述至少一个处理器执行的计算机程序，所述计算机程序被所述至少一个处理器执行，以使所述至少一个处理器能够执行上述的基于fetch优化前端数据交互的方法。
本申请取得的技术效果为：
本申请有别于传统的基于xhr的数据交互方法，采用基于原生的fetch技术，在满足数据交互的同时，提供了自定义超时时间、缓存设置、请求拦截器、响应拦截器、请求头、响应解析设置、异常标准化处理等高级定制化设置，丰富了数据请求过程，形成了业务场景全流程支持，同时，该方法底层天然支持Promise，和传统技术比，不存在回调地狱，拥有更好的性能、易接入和可维护性，在满足多业务场景和使用对接方面，比传统的其他数据请求方法更有优势。
 附图说明
图1是本申请所提供的fetch请求生成的流程图；
图2是本申请所提供的fetch请求的响应流程图。
 具体实施方式
为使本申请的上述目的、特征和优点能够更加明显易懂，下面结合说明书附图对本申请的具体实施方式做详细的说明。
在下面的描述中阐述了很多具体细节以便于充分理解本申请，但是本申请还可以采用其他不同于在此描述的其它方式来实施，本领域技术人员可以在不违背本申请内涵的情况下做类似推广，因此本申请不受下面公开的具体实施例的限制。
其次，此处所称的“一个实施例”或“实施例”是指可包含于本申请至少一个实现方式中的特定特征、结构或特性。在本说明书中不同地方出现的“在一个较佳的实施方式中”并非均指同一个实施例，也不是单独的或选择性的与其他实施例互相排斥的实施例。
请参阅图1和图2所示，本申请提供了一种基于fetch优化前端数据交互的方法，包括：
S1、获取网页配置以及其对应的配置参数，其中，网页配置包括全局配置和局域配置，局域配置覆盖全局配置，配置参数包括缓存开关、请求路径前缀、URL编码、请求方法、请求头、响应解析设置、请求参数的数据结构、公共参数、超时时间以及标准响应成功状态码；
S2、获取业务需求，并获取业务需求的请求方法，且开启body中包裹data的开关，再合并body.data对象到body中，并删除原有body.data对象；
S3、开启缓存开关，查询本地缓存中是否存在与业务需求对应的缓存数据，且在本地缓存内存在缓存数据时，直接调用该缓存数据，反之，则向服务端发送fetch请求；
S4、从服务端获取与fetch请求对应的响应数据，且同步生成待评估响应成功状态码，再将待评估响应成功状态码与标准响应成功状态码进行比对；
若待评估响应成功状态码与标准响应成功状态码一致，则根据缓存开关的状态处理对应的响应数据；
若待评估响应成功状态码与标准响应成功状态码不一致，则中断请求，并生成错误报告。
如上述步骤S1至S4，随着互联网的快速发展，前端技术也在不断地进步。在这个过程中，数据交互成为了前端开发的重要环节，传统的前端数据交互方式主要依赖于XMLHttpRequest(XHR)和jQuery等库，然而，这些方法在处理大量数据时存在性能瓶颈，导致用户体验不佳，为了解决这个问题，Fetch API应运而生，Fetch API是一个现代的网络请求API，它提供了一个全局的fetch()方法，可以用来获取资源，Fetch API的设计目标是提供一个简单、合理、可控的方式来处理网络请求，使得开发者可以更加专注于数据处理和业务逻辑。然而，尽管Fetch API在很多方面都优于传统的XHR和jQuery，但它仍然存在一定的局限性，如错误处理、超时控制等方面的问题，本实施例中，首先会从给定的网页配置中提取出全局配置和局域配置，其中，全局配置涉及到整个网页的宏观设置，而局域配置则更加具体，覆盖了特定区域的详细配置，这些配置参数包括缓存开关、请求路径前缀、URL编码、请求方法、请求头、响应解析设置、请求参数的数据结构、公共参数、超时时间以及标准响应成功状态码，为服务端和业务层提供了理解和处理网页配置的详细信息，在获取业务需求的过程中，服务端会特别关注请求方法，并开启body中包裹data的开关，这个步骤是为了合并body.data对象到body中，并删除原有的body.data对象，这样的处理使得数据更加集中和简洁，方便后续的数据处理和分析，在开启缓存开关后，业务层会查询本地缓存中是否存在与业务需求对应的缓存数据，如果存在，业务层会直接调用该缓存数据，如果不存在，则会向服务端发送fetch请求，这样的设计有效地减少了不必要的网络请求，提高了效率，从服务端获取与fetch请求对应的响应数据后，其会同步生成待评估响应成功状态码，接着，它会将这个待评估响应成功状态码与标准响应成功状态码进行比对，如果两者一致，会根据缓存开关的状态处理对应的响应数据，如果两者不一致，则会中断请求并生成错误报告，这样的处理方式保证了数据的准确性和一致性。
在一个较佳的实施方式中，缓存开关首次开启时，请求服务端数据，并将服务端数据保存至本地存储中，后续在业务需求发出后，会先行查询本地缓存中是否存在与业务需求对应的缓存数据，减少不必要网络请求的生成。
在一个较佳的实施方式中，请求路径前缀用于存放请求的共有路径，公共参数用于存放请求中共有的参数，请求参数数据结构支持URL、FORM表单、JSON结构提交到服务端，适配服务端数据需求。
全局定义路径前缀和拦截器，采用POST方式提交JSON数据到服务端完成数据交互。
[根据细则26改正 26.12.2024]
主体代码如下：
其实施步骤如下：
1)设置项目前缀prefix，prefix会附加在所有请求前面；
2)设置响应拦截器，当返回码是core.e1019(未登录)时，当前页面刷新，并返回false，阻止后续代码的执行；
3)业务调用ctFetch(本专利实施的函数名字)；
4)把method,transferType与全局配置合并；
5)data合并到fetch的body参数中；
6)由于设置了prefix，请求url变为/gw/user；
7)由于是POST方式请求，需设置HTTP请求头为application/json；
8)发出fetch请求；
9)数据正常返回；
10)解析返回的数据；
11)执行响应拦截器，逻辑已在第二步中描述；
12)检查响应状态码是否一致
13)返回服务端的解析数据res给到业务，整体流程结束。
在一个较佳的实施方式中，向服务端发送fetch请求之前，若存在用于验证参数有效性的请求拦截器，则业务层传递请求url和请求参数到请求拦截器数组，待所有请求拦截器执行完毕后才会发出fetch请求，反之，则直接生成fetch请求。
在该实施方式中，在向服务端发送fetch请求之前，首先需要考虑到一种情况，那就是当存在用于验证参数有效性的请求拦截器时，在这种情况下，业务层会将请求的url和请求参数传递到请求拦截器数组中，每一个请求拦截器都会对请求参数进行验证，确保参数的有效性，只有当所有的请求拦截器都执行完毕，确保了参数的有效性之后，才会真正发出fetch请求，反之，如果并不存在用于验证参数有效性的请求拦截器，那么业务层就会直接生成fetch请求，无需等待任何额外的验证步骤。这样的设计可以保证请求的及时性和效率，避免了不必要的等待时间。
在一个较佳的实施方式中，业务需求生成后，开启用于监听数据响应时长的超时监听器，且在数据响应返回超时后，则执行监听器代码，并取消后续响应，再报告超时错误给业务层，反之，若数据响应返回未超时，则取消监听器代码执行，并生成fetch请求。
在该实施方式中，在业务需求生成之后，启用超时监听器，一旦数据响应时间超过了预定阈值，这个装置就会触发预先设定的代码执行，及时取消后续响应，避免无谓的资源消耗，同时，装置会向业务层报告超时错误，以便业务层能及时了解并处理问题，如果数据响应时间没有超过预定阈值，超时监听器则会保持静默，等待下一次的数据响应任务，为业务层提供有力的数据保障。
其中，fetch请求向服务端发送后，会实时采集服务器状态以及网络状态；
若服务器状态或网络状态异常，则抛出服务器错误给业务层，并终止后续流程，反之，则服务端获取到数据，并表明fetch请求响应成功。
在一个较佳的实施方式中，fetch请求响应成功后的步骤，包括：
根据网页配置解析响应数据，并设置响应拦截器，且服务端传递请求url和响应数据到响应拦截器数组；
若响应拦截器返回错误，则终止后续所有程序执行，并抛出拦截器错误给业务层；
若所有响应拦截器执行完毕，且未返回错误，则同步生成待评估响应成功状态码。
如上述，在fetch请求成功后，首先根据网页的配置信息，对响应数据进行解析，并设置一个响应拦截器，这个拦截器在服务端传递请求url和响应数据后开始运行，它将这些数据传递到响应拦截器数组中，以便后续处理，然后，如果响应拦截器返回错误，那么会立即终止后续所有程序的执行，并将这个拦截器错误抛出给业务层，这样，业务层就能快速了解并处理问题，最后，如果所有的响应拦截器都执行完毕，并且没有返回错误，那么就会同步生成一个待评估响应成功状态码，这个状态码可以用来判断请求是否成功，以及成功后的响应数据应该如何处理，通过这种方式，我们可以确保在请求成功后，所有的步骤都能正确执行，并且能有效地处理响应数据。
其中，根据缓存开关的状态处理对应的响应数据的步骤，包括：
获取缓存开关的状态，判断其是否开启；
若缓存开关开启，则将该响应数据添加至本地存储中；
若缓存开关关闭，则直接筛除该响应数据。
在该实施方式中，缓存开关针对本地缓存进行设置，即在缓存开关开启之后，服务端响应数据能够加入至本地缓存之中，方便后续业务层的直接调用，本地缓存内的响应数据可以根据使用者的需求进行设置，也可以根据调用频次进行设置，其目的旨在于加快数据响应，并减少不必要的网络请求。
本申请还提供了，一种基于fetch优化前端数据交互的系统，应用于上述的基于fetch优化前端数据交互的方法，所述系统包括：
配置模块，配置模块用于获取网页配置以及其对应的配置参数，其中，网页配置包括全局配置和局域配置，局域配置覆盖全局配置，配置参数包括缓存开关、请求路径前缀、URL编码、请求方法、请求头、响应解析设置、请求参数的数据结构、公共参数、超时时间以及标准响应成功状态码；
请求模块，请求模块用于获取业务需求，并获取业务需求的请求方法，且开启body中包裹data的开关，再合并body.data对象到body中，并删除原有body.data对象；
调用模块，调用模块用于开启缓存开关，查询本地缓存中是否存在与业务需求对应的缓存数据，且在本地缓存内存在缓存数据时，直接调用该缓存数据，反之，则向服务端发送fetch请求；
响应模块，响应模块用于从服务端获取与fetch请求对应的响应数据，且同步生成待评估响应成功状态码，再将待评估响应成功状态码与标准响应成功状态码进行比对；
若待评估响应成功状态码与标准响应成功状态码一致，则根据缓存开关的状态处理对应的响应数据；
若待评估响应成功状态码与标准响应成功状态码不一致，则中断请求，并生成错误报告。
上述中，该系统执行时，首先通过配置模块来获取网页的配置信息及参数，再通过请求模块获取业务需求，开启在请求体中包含数据的开关，将body.data对象合并到请求体中，并删除原有的body.data对象，而后利用调用模块查询本地缓存中是否存在与业务需求对应的缓存数据，如果存在，直接使用该缓存数据；如果不存在，向服务端发送fetch请求，最后执行相应模块对fetch请求进行响应，并输出对应的响应数据即可。
以及，一种基于fetch优化前端数据交互的终端，包括：
至少一个处理器；
以及与至少一个处理器通信连接的存储器；
其中，存储器存储有可被至少一个处理器执行的计算机程序，计算机程序被至少一个处理器执行，以使至少一个处理器能够执行上述的基于fetch优化前端数据交互的方法。
需要说明的是，在本文中，术语“包括”、“包含”或者其任何其它变体意在涵盖非排他性的包含，从而使得包括一系列要素的过程、装置、物品或者方法不仅包括那些要素，而且还包括没有明确列出的其它要素，或者是还包括为这种过程、装置、物品或者方法所固有的要素。在没有更多限制的情况下，由语句“包括一个……”限定的要素，并不排除在包括该要素的过程、装置、物品或者方法中还存在另外的相同要素。
以上所述仅是本申请的可选实施方式，应当指出，对于本技术领域的普通技术人员来说，在不脱离本申请原理的前提下，还可以作出若干改进和润饰，这些改进和润饰也应视为本申请的保护范围。本申请中未具体描述和解释说明的结构、装置以及操作方法，如无特别说明和限定，均按照本领域的常规手段进行实施。

Claims (10)

  1. 一种基于fetch优化前端数据交互的方法，其特征在于：包括：
    获取网页配置以及其对应的配置参数，其中，所述网页配置包括全局配置和局域配置，所述局域配置覆盖全局配置，所述配置参数包括缓存开关、请求路径前缀、URL编码、请求方法、请求头、响应解析设置、请求参数的数据结构、公共参数、超时时间以及标准响应成功状态码；
    获取业务需求，并获取所述业务需求的请求方法，且开启body中包裹data的开关，再合并body.data对象到body中，并删除原有body.data对象；
    开启缓存开关，查询本地缓存中是否存在与业务需求对应的缓存数据，且在本地缓存内存在缓存数据时，直接调用该缓存数据，反之，则向服务端发送fetch请求；
    从所述服务端获取与fetch请求对应的响应数据，且同步生成待评估响应成功状态码，再将所述待评估响应成功状态码与标准响应成功状态码进行比对；
    若所述待评估响应成功状态码与标准响应成功状态码一致，则根据缓存开关的状态处理对应的响应数据；
    若所述待评估响应成功状态码与标准响应成功状态码不一致，则中断请求，并生成错误报告。
  2. 根据权利要求1所述的基于fetch优化前端数据交互的方法，其特征在于：所述缓存开关首次开启时，请求服务端数据，并将所述服务端数据保存至本地存储中。
  3. 根据权利要求1所述的基于fetch优化前端数据交互的方法，其特征在于：所述请求路径前缀用于存放请求的共有路径，所述公共参数用于存放请求中共有的参数，所述请求参数数据结构支持URL、FORM表单、JSON结构提交到服务端，适配服务端数据需求。
  4. 根据权利要求1所述的基于fetch优化前端数据交互的方法，其特征在于：所述向服务端发送fetch请求之前，若存在用于验证参数有效性的请求拦截器，则业务层传递请求url和请求参数到请求拦截器数组，待所有所述请求拦截器执行完毕后才会发出fetch请求，反之，则直接生成fetch请求。
  5. 根据权利要求1所述的基于fetch优化前端数据交互的方法，其特征在于：所述业务需求生成后，开启用于监听数据响应时长的超时监听器，且在所述数据响应返回超时后，则执行监听器代码，并取消后续响应，再报告超时错误给业务层，反之，若数据响应返回未超时，则取消监听器代码执行，并生成fetch请求。
  6. 根据权利要求1所述的基于fetch优化前端数据交互的方法，其特征在于：所述fetch请求向服务端发送后，实时采集服务器状态以及网络状态；
    若所述服务器状态或网络状态异常，则抛出服务器错误给业务层，并终止后续流程，反之，则服务端获取到数据，并表明fetch请求响应成功。
  7. 根据权利要求6所述的基于fetch优化前端数据交互的方法，其特征在于：所述fetch请求响应成功后的步骤，包括：
    根据网页配置解析响应数据，并设置响应拦截器，且服务端传递请求url和响应数据到响应拦截器数组；
    若所述响应拦截器返回错误，则终止后续所有程序执行，并抛出拦截器错误给业务层；
    若所有响应拦截器执行完毕，且未返回错误，则同步生成待评估响应成功状态码。
  8. 根据权利要求1所述的基于fetch优化前端数据交互的方法，其特征在于：所述根据缓存开关的状态处理对应的响应数据的步骤，包括：
    获取缓存开关的状态，判断其是否开启；
    若所述缓存开关开启，则将该响应数据添加至本地存储中；
    若所述缓存开关关闭，则直接筛除该响应数据。
  9. 一种基于fetch优化前端数据交互的系统，应用于权利要求1至8中任意一项所述的基于fetch优化前端数据交互的方法，其特征在于：所述系统包括：
    配置模块，所述配置模块用于获取网页配置以及其对应的配置参数，其中，所述网页配置包括全局配置和局域配置，所述局域配置覆盖全局配置，所述配置参数包括缓存开关、请求路径前缀、URL编码、请求方法、请求头、响应解析设置、请求参数的数据结构、公共参数、超时时间以及标准响应成功状态码；
    请求模块，所述请求模块用于获取业务需求，并获取所述业务需求的请求方法，且开启body中包裹data的开关，再合并body.data对象到body中，并删除原有body.data对象；
    调用模块，所述调用模块用于开启缓存开关，查询本地缓存中是否存在与业务需求对应的缓存数据，且在本地缓存内存在缓存数据时，直接调用该缓存数据，反之，则向服务端发送fetch请求；
    响应模块，所述响应模块用于从所述服务端获取与fetch请求对应的响应数据，且同步生成待评估响应成功状态码，再将所述待评估响应成功状态码与标准响应成功状态码进行比对；
    若所述待评估响应成功状态码与标准响应成功状态码一致，则根据缓存开关的状态处理对应的响应数据；
    若所述待评估响应成功状态码与标准响应成功状态码不一致，则中断请求，并生成错误报告。
  10. 一种基于fetch优化前端数据交互的终端，其特征在于：包括：
    至少一个处理器；
    以及与所述至少一个处理器通信连接的存储器；
    其中，所述存储器存储有可被所述至少一个处理器执行的计算机程序，所述计算机程序被所述至少一个处理器执行，以使所述至少一个处理器能够执行权利要求1至8中任意一项所述的基于fetch优化前端数据交互的方法。
PCT/CN2024/135496 2023-12-13 2024-11-29 一种基于fetch优化前端数据交互的方法、系统和终端 Pending WO2025124161A1 (zh)

Applications Claiming Priority (2)

Application Number Priority Date Filing Date Title
CN202311712625.6A CN117874382A (zh) 2023-12-13 2023-12-13 一种基于fetch优化前端数据交互的方法
CN202311712625.6 2023-12-13

Publications (1)

Publication Number Publication Date
WO2025124161A1 true WO2025124161A1 (zh) 2025-06-19

Family

ID=90578224

Family Applications (1)

Application Number Title Priority Date Filing Date
PCT/CN2024/135496 Pending WO2025124161A1 (zh) 2023-12-13 2024-11-29 一种基于fetch优化前端数据交互的方法、系统和终端

Country Status (2)

Country Link
CN (1) CN117874382A (zh)
WO (1) WO2025124161A1 (zh)

Cited By (1)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
CN120912160A (zh) * 2025-07-25 2025-11-07 西藏翔龙矿业有限公司 一种矿业权招拍挂信息自动监测及邮件提醒方法

Families Citing this family (3)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
CN117874382A (zh) * 2023-12-13 2024-04-12 天翼云科技有限公司 一种基于fetch优化前端数据交互的方法
CN118364016A (zh) * 2024-04-19 2024-07-19 浪潮云信息技术股份公司 一种接口缓存方法及装置
CN118449782B (zh) * 2024-07-05 2024-09-06 成都数之联科技股份有限公司 基于乾坤微服务的应用请求处理方法、装置、设备及介质

Citations (6)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
CN111259283A (zh) * 2018-11-30 2020-06-09 阿里巴巴集团控股有限公司 一种页面资源预加载的处理方法及装置，电子和存储设备
US20210096825A1 (en) * 2019-09-30 2021-04-01 Salesforce.Com, Inc. Systems, methods, and apparatuses for local web components development within a cloud based computing environment
CN115878699A (zh) * 2022-10-25 2023-03-31 超聚变数字技术有限公司 处理前端设备的Mock数据的方法和前端设备
CN116302175A (zh) * 2023-02-09 2023-06-23 平安付科技服务有限公司 一种并发网络请求处理方法、装置、设备及存储介质
CN117076492A (zh) * 2023-09-04 2023-11-17 中国联合网络通信集团有限公司 业务数据查询方法、装置、设备及存储介质
CN117874382A (zh) * 2023-12-13 2024-04-12 天翼云科技有限公司 一种基于fetch优化前端数据交互的方法

Family Cites Families (2)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
CN112667948B (zh) * 2020-12-30 2023-02-07 杭州天阙科技有限公司 基于Fetch的数据通信方法和系统
CN112965739B (zh) * 2021-02-08 2024-02-09 中国工商银行股份有限公司 前端http请求处理方法、装置及系统

Patent Citations (6)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
CN111259283A (zh) * 2018-11-30 2020-06-09 阿里巴巴集团控股有限公司 一种页面资源预加载的处理方法及装置，电子和存储设备
US20210096825A1 (en) * 2019-09-30 2021-04-01 Salesforce.Com, Inc. Systems, methods, and apparatuses for local web components development within a cloud based computing environment
CN115878699A (zh) * 2022-10-25 2023-03-31 超聚变数字技术有限公司 处理前端设备的Mock数据的方法和前端设备
CN116302175A (zh) * 2023-02-09 2023-06-23 平安付科技服务有限公司 一种并发网络请求处理方法、装置、设备及存储介质
CN117076492A (zh) * 2023-09-04 2023-11-17 中国联合网络通信集团有限公司 业务数据查询方法、装置、设备及存储介质
CN117874382A (zh) * 2023-12-13 2024-04-12 天翼云科技有限公司 一种基于fetch优化前端数据交互的方法

Cited By (1)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
CN120912160A (zh) * 2025-07-25 2025-11-07 西藏翔龙矿业有限公司 一种矿业权招拍挂信息自动监测及邮件提醒方法

Also Published As

Publication number Publication date
CN117874382A (zh) 2024-04-12

Similar Documents

Publication Publication Date Title
CN117874382A (zh) 一种基于fetch优化前端数据交互的方法
US8751587B2 (en) Real-time web applications
US8689234B2 (en) Providing real-time widgets in a web application framework
CN110413418B (zh) 缓存同步装置及方法，缓存同步系统、电子设备
CN110351315A (zh) 数据处理的方法、系统及存储介质、电子装置
CN110224896B (zh) 一种网络性能数据采集方法、装置及存储介质
US8683357B2 (en) Providing real time web application framework socket
CN107257363B (zh) 一种响应请求端请求的方法及系统
US20150067013A1 (en) Methods for servicing web service requests using parallel agile web services and devices thereof
US20110125834A1 (en) Architecture, system and method for providing a plug-in architecture in a real-time web application framework
CN102387354A (zh) 一种基于嵌入式Web服务器的视频监控系统
CN103618732B (zh) 一种PaaS与Erlang App应用引擎架构执行流程
CN111723314A (zh) 网页展示方法、装置、电子设备及计算机可读存储介质
CN105516337B (zh) 基于动态加载机制的web站点对接解析方法
CN116662430A (zh) 应用于多系统交互的数据查询方法、装置、设备、介质和产品
US9374437B2 (en) Schema validation proxy
EP4660820A1 (en) Client-dominated information publishing system
JP2025540743A (ja) データ伝送方法、装置、伝送機器、端末機器、及びコンピュータプログラム
CN118445503A (zh) 一种生成pdf文件的方法和系统
CN115580605A (zh) 基于微服务的请求处理方法及装置
CN115643431A (zh) 请求处理方法、装置、计算机设备及存储介质
CN115714818B (zh) 数据处理方法及装置、服务器及存储介质
CN113868298A (zh) 一种数据加载方法、装置、设备及介质
CN111443987A (zh) 一种基于web系统的图像视频脚本处理系统及方法
CN116055569B (zh) 自定义切换时区的方法、系统、计算机设备和存储介质

Legal Events

Date Code Title Description
121 Ep: the epo has been informed by wipo that ep was designated in this application

Ref document number: 24902583

Country of ref document: EP

Kind code of ref document: A1