Applet request extension management method and device, and medium
Patent Information
- Application Number
- CN202611140908.1
- Authority / Receiving Office
- CN · China
- Patent Type
- Applications(China)
- Current Assignee / Owner
- Filing Date
- 2026-07-29
- Publication Date
- 2026-10-30
AI Technical Summary
[0035]本申请提供一种小程序请求扩展管理方法、装置及介质，客户端通过配置灵活发送不同类型的请求，服务端通过配置响应公共逻辑避免重复写代码，避免回调地狱和Loading和Toast冲突异常。
Smart Images
Figure CN123011205A_ABST
Abstract
Description
Technical Field
[0001] This application relates at least to the field of network technology, and in particular to a method, apparatus and medium for managing mini-program request extensions. Background Technology
[0002] During software project development, as the business logic of mini-programs becomes increasingly complex, the number of server-side interfaces that need to be connected increases. Different developers have different interface standards, which makes it necessary for mini-program clients to more flexibly encapsulate requests and dynamically configure them to meet business requirements. Summary of the Invention
[0003] To address the aforementioned shortcomings, this application provides a method, apparatus, and medium for managing extended requests in mini-programs, thereby solving the following technical problem: how to flexibly encapsulate requests and dynamically configure them to meet business requirements.
[0004] Firstly, this application provides a method for managing mini-program request extensions, the method comprising:
[0005] Define a unified management system for request parameter bodies across multiple interfaces, including: using Promise calls to avoid callback hell, using aborts to avoid request conflicts during switching, uniformly encapsulating requests and file uploads, and using timestamps to avoid request caching;
[0006] Configure the server-side common response logic for the request parameter body, including: configuring Loading and Toast and handling display conflicts;
[0007] Configure request parameters in the request parameter body to initiate a request to the target mini-program;
[0008] The response to the target mini-program's request is obtained based on the server-side common response logic.
[0009] Furthermore, a unified management system for request parameter bodies across multiple interfaces is defined, including: using Promise calls to avoid callback hell, using aborts to avoid request conflicts during switching, uniformly encapsulating requests and file uploads, and using timestamps to avoid request caching. Specifically, this includes:
[0010] Define the public attributes and methods for the request: baseUrl, dealwithToken, and dealwith401. Here, baseUrl represents the public path, dealwithToken represents obtaining the token, and dealwith401 represents the logic for handling 401.
[0011] Define request parameters abort, type, method, url, data, errorStatus, loadingStatus, and header. Here, abort indicates that the request can be aborted, type indicates the basic request or file upload, method indicates the request method, url indicates the path, data indicates the upload data, errorStatus indicates whether to display an error message, loadingStatus indicates whether to display the loading status, and header indicates common request headers.
[0012] To avoid callback hell, use `new Promise` to make the `wx.request`, `wx.uploadFile`, and `wx.downloadFile` methods Promise-ify them. Add a timestamp to the URL suffix to avoid caching. `preRequest` stores the previous request. When `abort` is true, calling `preRequest.abort` will abort the request. The `type` value determines whether to call `wx.request`, `wx.uploadFile`, or `wx.downloadFile`.
[0013] Furthermore, the server-side common response logic for the request parameter body is set as follows:
[0014] Get the response data statusCode;
[0015] When the statusCode is 200, Promise.resolve returns data;
[0016] When the statusCode is 404, output a Toast message indicating a path error.
[0017] When the statusCode is 401, the passed-in processing function is called;
[0018] When the statusCode is 500 or other backend-defined errors, parse the corresponding body's structure error output;
[0019] When the fail callback is executed, it checks whether the request has timed out, handles domain name resolution errors accordingly, and checks the boolean values of the parameters showError and showLoading to determine whether to output the error message and display the loading icon.
[0020] Furthermore, the request parameters are configured in the request parameter body to initiate a request to the target mini-program, specifically including:
[0021] Import the request.js file, call the requestConfig method, configure the common parameters baseUrl, dealwithToken, and dealwith401, select the 401 handling function by configuring dealwith401, pass in the corresponding parameters of the server's HTTP protocol, execute the code call, and initiate a request to the target mini-program.
[0022] Furthermore, the target mini-program request specifically includes:
[0023] The target mini-program must make at least one of the following requests: GET request, POST request, wx.uploadFile upload interface request, or wx.downloadFile download interface request.
[0024] Furthermore, initiate a request to the target mini-program, specifically including:
[0025] The system uses a fuzzy search to determine if a previous request is currently in progress. If so, it stops the previous request and initiates the current request using the interface with the latest time.
[0026] Furthermore, obtaining the response to the target mini-program request based on the server-side common response logic specifically includes:
[0027] The system handles request URL caching and token injection, obtains status codes, and uses the server-side common response logic based on the status codes to obtain the response to the target mini-program request.
[0028] Secondly, this application provides a mini-program request extension management device, the device comprising:
[0029] The definition module is used to define the request parameter body for unified management of multiple interfaces, including defining: using Promise calls to avoid callback hell, avoiding request conflicts during switching through abort, uniformly encapsulating requests and file uploads, and using timestamps to avoid request caching;
[0030] The configuration module, connected to the definition module, is used to set the server-side common response logic of the request parameter body, including setting: Loading and Toast configuration and handling display conflicts;
[0031] The request module, connected to the settings module, is used to configure request parameters in the request parameter body to initiate a request to the target mini-program.
[0032] The response module, connected to the request module, is used to obtain the response to the request of the target mini-program based on the server-side common response logic.
[0033] Thirdly, this application provides a computer device, the computer device including a processor and a memory, the memory storing a computer program, and when the processor runs the computer program stored in the memory, the processor executes the applet request extension management method as described above.
[0034] Fourthly, this application provides a computer-readable storage medium storing a computer program that, when executed by a processor, implements the applet request extension management method described above.
[0035] This application provides a method, device, and medium for managing mini-program requests. The client can flexibly send different types of requests through configuration, and the server can avoid writing repetitive code by configuring common response logic, thus avoiding callback hell and Loading and Toast conflicts and exceptions. Attached Figure Description
[0036] Figure 1 This is a flowchart of a method for managing mini-program request extensions according to an embodiment of this application;
[0037] Figure 2 It is a flowchart of an existing technology interface that requires multiple processing logics;
[0038] Figure 3 This is a flowchart illustrating a method for initiating a request according to an embodiment of this application;
[0039] Figure 4 This is a schematic diagram of the structure of a mini-program request extension management device according to an embodiment of this application;
[0040] Figure 5 This is a schematic diagram of the structure of a computer device according to an embodiment of this application;
[0041] Figure 6 This is a schematic diagram of the structure of a computer-readable storage medium according to an embodiment of this application. Detailed Implementation
[0042] To enable those skilled in the art to better understand the technical solution of this application, the embodiments of this application will be further described in detail below with reference to the accompanying drawings.
[0043] It is understood that the specific embodiments and accompanying drawings described herein are merely for explaining this application and are not intended to limit this application.
[0044] It is understood that, without conflict, the various embodiments and features in the embodiments of this application can be combined with each other.
[0045] It is understood that, for ease of description, only the parts relevant to this application are shown in the accompanying drawings, while parts unrelated to this application are not shown in the drawings.
[0046] It is understood that each module or unit involved in the embodiments of this application may correspond to only one entity structure, or may be composed of multiple entity structures, or multiple modules or units may be integrated into one entity structure.
[0047] It is understood that, without conflict, the functions and steps indicated in the flowcharts and block diagrams of this application may occur in a different order than that indicated in the accompanying drawings.
[0048] It is understood that the flowcharts and block diagrams of this application illustrate the possible architecture, functions, and operations of systems, apparatuses, devices, and methods according to various embodiments of this application. Each block in a flowchart or block diagram may represent a module, unit, program segment, or code, containing executable instructions for implementing the specified function. Furthermore, each block or combination of blocks in the block diagrams and flowcharts may be implemented using a hardware-based device to implement the specified function, or using a combination of hardware and computer instructions.
[0049] It is understood that the modules and units involved in the embodiments of this application can be implemented by software or by hardware. For example, the modules and units can be located in the processor.
[0050] Example 1:
[0051] like Figure 1 As shown, this application provides a method for managing mini-program request extensions, the method comprising:
[0052] S1. Define a unified management system for request parameter bodies of various interfaces, including: using Promise calls to avoid callback hell, using abort to avoid request conflicts during switching, uniformly encapsulating requests and file uploads, and using timestamps to avoid request caching.
[0053] S2. Configure the server-side common response logic for the request parameter body, including setting: Loading and Toast configuration and handling display conflicts;
[0054] S3. Configure request parameters in the request parameter body to initiate a request to the target mini-program;
[0055] S4. Obtain the response to the target mini-program request based on the server-side common response logic.
[0056] In this embodiment, the provided method allows the client to flexibly send different types of requests through configuration, and the server to avoid repetitive code writing by configuring common response logic, thus avoiding callback hell and Loading and Toast conflict exceptions.
[0057] Specifically, this embodiment provides a mini-program request device to overcome the following disadvantages of the prior art:
[0058] 1. Common logic such as token expiration, interface not found, authentication failure, and request timeout needs to be intercepted and handled uniformly, rather than being checked separately for each interface, which leads to a lot of code duplication, as shown in the following traditional implementation:
[0059] / / GET request
[0060] wx.request({
[0061] method:'get',
[0062] success(){
[0063] / / Check for a 200 success error and follow the processing flow.
[0064] / / Determine the 404 interface path
[0065] / / Timeout Detection
[0066] / / Determine the service's error message
[0067] },
[0068] })
[0069] / / POST request
[0070] wx.request({
[0071] method:'post',
[0072] success(){
[0073] / / Check for a 200 success error and follow the processing flow.
[0074] / / Determine the 404 interface path
[0075] / / Timeout Detection
[0076] / / Determine the service's error message
[0077] },
[0078] })
[0079] 2. Uploading resources, downloading resources, obtaining user information, and stopping the previous request when switching menus all require separate encapsulation of WeChat API calls for each scenario. This increases the workflow, makes the code difficult to understand, and is redundant, as shown in the traditional implementation below:
[0080] / / Upload Interface
[0081] wx.uploadFile({
[0082] uel:'xxxx',
[0083] name:'xxx',
[0084] success(){
[0085] / / Check for a 200 success error and follow the processing flow.
[0086] / / Determine the 404 interface path
[0087] / / Timeout Detection
[0088] / / Determine the service's error message
[0089] },
[0090] })
[0091] / / Download interface
[0092] wx.downloadFile({
[0093] uel:'',
[0094] type:'xxx',
[0095] success(){
[0096] / / Check for a 200 success error and follow the processing flow.
[0097] / / Determine the 404 interface path
[0098] / / Timeout Detection
[0099] / / Determine the service's error message
[0100] },
[0101] })
[0102] 3. The same API call requires multiple logic processing steps, and different APIs also require multiple logic processing steps, making the code complex and difficult to understand, as shown in the attached document. Figure 2 The flowchart shown is the entire process.
[0103] In general, the drawbacks of existing technologies include: clients cannot flexibly configure the sending of different types of requests, such as GET and POST requests, and file uploads and downloads; server-side response logic is repeatedly written, resulting in redundant and difficult-to-maintain code; callback hell occurs when multiple requests depend on each other for execution; and loading and toast conflicts occur.
[0104] In view of this, the objectives of this embodiment include: adding request Promise-based functionality to facilitate Promise calls and avoid callback hell; aborting to avoid request conflicts during switching; unified encapsulation of requests and file uploads; timestamps to avoid request caching; configurable Loading and Toast functions to handle display conflicts; unified processing of common logic; less code required; and improved development efficiency.
[0105] This embodiment specifically enables flexible configuration for sending different types of requests, such as uniformly encapsulating GET and POST requests and uploading / downloading files; and uniformly handling common status codes in server responses, such as unifying the interception and response processing logic for common status codes like TOKEN expiration and interface timeout, avoiding a large amount of code duplication. Developers can focus on developing specific logic while reducing the processing of common logic, improving development efficiency and enhancing code readability and maintainability.
[0106] This embodiment not only unifies the Promise-based implementation of the wx.request method in WeChat Mini Programs and the output of error information, but also extends this functionality to include file upload, API caching, request cancellation, Loading and Toast configurations, thus improving usability. It encapsulates APIs and provides parameter configuration options for users, enhancing scalability through parameter customization. It also provides logical responses to different server status codes and unifies common client operations, such as avoiding caching, configuring baseUrl, and Promise-based implementation.
[0107] In one implementation, a unified request parameter body for managing multiple interfaces is defined, including: using Promise calls to avoid callback hell, using aborts to avoid request conflicts during switching, uniformly encapsulating requests and file uploads, and using timestamps to avoid request caching. Specifically, this includes:
[0108] Define the public attributes and methods for the request: baseUrl, dealwithToken, and dealwith401. Here, baseUrl represents the public path, dealwithToken represents obtaining the token, and dealwith401 represents the logic for handling 401.
[0109] Define request parameters abort, type, method, url, data, errorStatus, loadingStatus, and header. Here, abort indicates that the request can be aborted, type indicates the basic request or file upload, method indicates the request method, url indicates the path, data indicates the upload data, errorStatus indicates whether to display an error message, loadingStatus indicates whether to display the loading status, and header indicates common request headers.
[0110] To avoid callback hell, use `new Promise` to make the `wx.request`, `wx.uploadFile`, and `wx.downloadFile` methods Promise-ify them. Add a timestamp to the URL suffix to avoid caching. `preRequest` stores the previous request. When `abort` is true, calling `preRequest.abort` will abort the request. The `type` value determines whether to call `wx.request`, `wx.uploadFile`, or `wx.downloadFile`.
[0111] In this embodiment, a method for managing extended devices based on mini-program requests is provided, and the technical solution adopted includes the following steps:
[0112] Step 1: Configure request parameters
[0113] 1) Define the public request attributes and methods: baseUrl (public path), dealwithToken (get token), and dealwith401 (logic for handling 401 errors). The following code can be used to implement this:
[0114] / **
[0115] *
[0116] *@param baseURL string Domain URL
[0117] *@param delwithToken function Get token
[0118] *@param dealwith401 function Custom 401 handling method
[0119] /
[0120] const requestConfig = ({
[0121] baseUrl = '',
[0122] delwithToken = () => wx.getStorageSynv('token'),
[0123] dealwith401 = () =>{
[0124] wx.navigateTo({
[0125] url:' / pages / login / login ',
[0126] })
[0127] },
[0128] }) => {
[0129] 2) Define request parameters: abort (request can be aborted), type (basic request or file upload), method (request method), url (path), data (upload data), errorStatus (whether to display an error message), loadingStatus (whether to display loading status), and header (common request headers). The following code can be used to implement this:
[0130] / **
[0131] *
[0132] *@param abort string Whether it can be cancelled
[0133] *@param type string Request type
[0134] *@param method string Request method
[0135] *@param url string Request path
[0136] *@param data string Request data
[0137] *@param loadingStatus boolean Request status
[0138] *@param errorStatus boolean Error status
[0139] *@param rest object Request other parameters
[0140] /
[0141] Return function ({
[0142] abort = false,
[0143] type = 'request',
[0144] method = 'get',
[0145] url,
[0146] data = {}
[0147] loadingStatus = true,
[0148] errorStatus = true,
[0149] header,
[0150] …rest
[0151] }){
[0152] 3) Use `new Promise` to make the `wx.request`, `wx.uploadFile`, and `wx.downloadFile` methods Promise-ified to avoid callback hell. Add a timestamp to the URL suffix to avoid caching. `preRequest` stores the previous request. When `abort` is true, calling `preRequest.abort` will abort the request. The `type` value determines whether to call `wx.request`, `wx.uploadFile`, or `wx.downloadFile`. This can be implemented using the following code:
[0153] Return new Promise((resolve,reject) => {
[0154] const_url = '${baseUrl}${url}?time=${Date.now()}'
[0155] if (abort && preRequest) preRequest.abort()
[0156] const error = new Error('System Busy')
[0157] error.code = '500'
[0158] let target = {
[0159] url:_url ,
[0160] header:{
[0161] token:typeof dealwithToken === 'function' && dealwithToken(),
[0162] cookie:typeof dealwithToken === 'function' && dealwithToken(),
[0163] …header,
[0164] },
[0165] …rest,
[0166] }
[0167] / / request
[0168] If (type ==='request'){
[0169] Target = {
[0170] method,
[0171] data,
[0172] …target,
[0173] }
[0174] }
[0175] / / upload
[0176] else if (type ==='uploadFile'){
[0177] const{filePath, name, …formData} =data
[0178] target = {
[0179] filePath,
[0180] name,
[0181] formData,
[0182] …target,
[0183] }
[0184] }
[0185] / / download
[0186] else if (type ==='downloadFile'){
[0187] target = {
[0188] …target,
[0189] }
[0190] }
[0191] loadingStatus && wx.showLoading({title:'Loading...'})
[0192] preRequest = wx[type]({…
[0193] })
[0194] In one implementation, the server-side common response logic for setting the request parameter body is as follows:
[0195] Get the response data statusCode;
[0196] When the statusCode is 200, Promise.resolve returns data;
[0197] When the statusCode is 404, output a Toast message indicating a path error.
[0198] When the statusCode is 401, the passed-in processing function is called;
[0199] When the statusCode is 500 or other backend-defined errors, parse the corresponding body's structure error output;
[0200] When the fail callback is executed, it checks whether the request has timed out, handles domain name resolution errors accordingly, and checks the boolean values of the parameters showError and showLoading to determine whether to output the error message and display the loading icon.
[0201] In this embodiment, a method for managing extended devices based on mini-program requests is provided, and the technical solution adopted includes the following steps:
[0202] Step 2: Process the common response logic on the server side
[0203] When the response data `statusCode` is 200, `Promise.resolve` returns `data`; when `statusCode` is 404, a path exception is displayed using a Toast message; when `statusCode` is 401, the passed-in processing function is called; when `statusCode` is 500 or another backend-defined error, the structure of the response body is parsed and an error message is displayed; when the `fail` callback is called, it checks if the request timed out, handles domain name resolution exceptions accordingly, and finally checks the boolean values of the parameters `showError` and `showLoading` to determine whether to output the response error and display the loading icon; This can be implemented using the following code:
[0204] PreRequest = wx[type]({
[0205] …target,
[0206] success(response) => {
[0207] const {statusCode,data} = response
[0208] if (statusCode === 200){ / / Process 200
[0209] resolve(data)
[0210] }else if (statusCode === 404){ / / Handle 404
[0211] error.code = statusCode
[0212] error.message = 'Path error'
[0213] reject(error)
[0214] }else if (statusCode === 401){ / / Handle 401
[0215] error.code = statusCode
[0216] error.message = 'Authentication failed'
[0217] reject(error)
[0218] dealwith401 && dealtith401()
[0219] }else { / / Handle other errors
[0220] error.message = data.maessage || data.mag || error.message
[0221] error.code = data.code || data.status || statusCode
[0222] reject(error)
[0223] }
[0224] if (statusCode !== 200 && errorStatus){ / / Output exception information
[0225] wx.showToast({
[0226] title:error.message,
[0227] icon:'none',
[0228] })
[0229] }else{
[0230] loadingStatus && wx.hideLoading()
[0231] }
[0232] },
[0233] fail:(err) => {
[0234] / / Other exceptions
[0235] const {errMsg} = err || {}
[0236] error.message = errMsg || 'Domain name resolution error'
[0237] / / Handling timeout
[0238] if (errMsg === 'request:fail timeout'){
[0239] error.message = 'Request timed out'
[0240] }
[0241] reject(error)
[0242] if(errorStatus){
[0243] wx.showToast({
[0244] title:error.message,
[0245] icon:'none',
[0246] })
[0247] }else{
[0248] loadingStatus && wx.hideLoading()
[0249] }
[0250] },
[0251] })
[0252] In one embodiment, configuring request parameters in the request parameter body to initiate a request to the target mini-program specifically includes:
[0253] Import the request.js file, call the requestConfig method, configure the common parameters baseUrl, dealwithToken, and dealwith401, select the 401 handling function by configuring dealwith401, pass in the corresponding parameters of the server's HTTP protocol, execute the code call, and initiate a request to the target mini-program.
[0254] In one implementation, the target mini-program request specifically includes:
[0255] The target mini-program must make at least one of the following requests: GET request, POST request, wx.uploadFile upload interface request, or wx.downloadFile download interface request.
[0256] In one implementation, initiating a request to the target mini-program specifically includes:
[0257] The system uses a fuzzy search to determine if a previous request is currently in progress. If so, it stops the previous request and initiates the current request using the interface with the latest time.
[0258] In one implementation, obtaining the response to the target mini-program request based on the server-side common response logic specifically includes:
[0259] The system handles request URL caching and token injection, obtains status codes, and uses the server-side common response logic based on the status codes to obtain the response to the target mini-program request.
[0260] In this embodiment, a method for managing extended devices based on mini-program requests is provided. The technical solution adopted includes the following steps:
[0261] Step 3: Initiate a request
[0262] Import the request.js file, call the requestConfig method, optionally configuring the baseURL base path and the 401 handling function, and pass in the corresponding parameters of the server's HTTP protocol to execute the code. A code example is shown below:
[0263] import requestConfig from '. / request'
[0264] export const request = requestConfig({
[0265] baseUrl:'http: / / 130.54.3.152.4000',
[0266] dealwithToken:() => {
[0267] wx.wx.getStorageSync('token')
[0268] },
[0269] dealwith401:() => {
[0270] wx.wx.navigateTo({
[0271] url:' / pages / login '
[0272] })
[0273] },
[0274] })
[0275] / / Normal request
[0276] request({
[0277] url:' / api / get ',
[0278] }).then((data) => {
[0279] console.log(data)
[0280] })
[0281] / / Error, including 500
[0282] request({
[0283] method:'post',
[0284] url:' / api / 500 ',
[0285] }).then((data) => {
[0286] console.log(data)
[0287] })
[0288] / / Upload
[0289] request({
[0290] type:'uploadFile',
[0291] url:' / api / upload ',
[0292] data:{
[0293] filePath:'xxx',
[0294] name:'xxx',
[0295] },
[0296] }).then((data) =>{
[0297] console.log(data)
[0298] })
[0299] / / Download
[0300] request({
[0301] type:'downloadFile',
[0302] url:'xxxx.png ',
[0303] }).then((data) => {
[0304] console.log(data)
[0305] })
[0306] / / Fuzzy search, anti-shake off Previous
[0307] request({
[0308] abort:true,
[0309] url:' / api / get ',
[0310] }), then((data) => {
[0311] console.log(data)
[0312] })
[0313] Step 3 is performed as shown in the attached diagram. Figure 3 The process shown includes:
[0314] Configure common parameters baseUrl, dealwithToken, and dealwith401;
[0315] Requests can be made using: GET requests, POST requests, wx.uploadFile upload requests, and wx.downloadFile download requests.
[0316] Handle request URL caching and token injection, determine whether to abort, and obtain a response or perform error handling based on whether the status code is 200, including handling errors such as status codes 401, 404, and request timeout.
[0317] The main features of the method in this embodiment include: custom public attributes and methods are injected into global requests, providing strong configurability; common request (wx.request, wx.uploadFile, wx.downloadFile) logic processing is encapsulated to simplify code; server response body logic (200, 401, 404, 500, timeout, other exceptions) is uniformly processed to reduce repetitive code, unify code format, and improve work efficiency; fuzzy search is implemented, and debouncing stops the previous request and initiates a request with the latest time interface.
[0318] The method described in this embodiment can be applied to mini-program development, such as cloud network mini-programs and government and enterprise mini-programs. This technology can be used as a unified request interception standard and published on GitLab, which is expected to reduce the amount of code, improve communication and code efficiency, avoid inconsistencies in backend interface standards, frontend interception, and rules for each project, and avoid inconsistent interceptor standards, which can lead to asynchronous development and difficulties in communication within the team.
[0319] Example 2:
[0320] like Figure 4 As shown, this application provides a mini-program request extension management device, the device comprising:
[0321] Define module 1, which is used to define the request parameter body for unified management of multiple interfaces, including defining: using Promise calls to avoid callback hell, avoiding request conflicts when switching through abort, uniformly encapsulating requests and file uploads, and using timestamps to avoid request caching;
[0322] Setting module 2, connected to definition module 1, is used to set the server-side common response logic of the request parameter body, including setting: Loading and Toast configuration and handling display conflicts;
[0323] Request module 3, connected to setting module 2, is used to configure request parameters in the request parameter body to initiate a request to the target mini-program;
[0324] The response module 4, connected to the request module 3, is used to obtain the response to the request of the target mini-program based on the server-side common response logic.
[0325] In one embodiment, module 1 is defined, specifically including:
[0326] The first definition unit is used to define the public attributes and methods of the request: baseUrl, dealwithToken, and dealwith401. Here, baseUrl represents the public path, dealwithToken represents obtaining the token, and dealwith401 represents the logic for handling 401.
[0327] The second definition unit is used to define the request parameters abort, type, method, url, data, errorStatus, loadingStatus, and header. Among them, abort indicates that the request can be aborted, type indicates the basic request or file upload, method indicates the request method, url indicates the path, data indicates the upload data, errorStatus indicates whether to display an error message, loadingStatus indicates whether to display the loading status, and header indicates the common request header.
[0328] The encapsulation unit, connected to the first definition unit and the second definition unit, is used to Promise the wx.request, wx.uploadFile, and wx.downloadFile methods using new Promise to avoid callback hell. A timestamp is added to the URL suffix to avoid caching. preRequest stores the previous request. When abort is true, calling preRequest.abort can abort the request. The type value determines whether to call wx.request, wx.uploadFile, or wx.downloadFile.
[0329] In one embodiment, the setting module 2 is specifically used for:
[0330] The server-side common response logic for the request parameter body is set as follows:
[0331] Get the response data statusCode;
[0332] When the statusCode is 200, Promise.resolve returns data;
[0333] When the statusCode is 404, output a Toast message indicating a path error.
[0334] When the statusCode is 401, the passed-in processing function is called;
[0335] When the statusCode is 500 or other backend-defined errors, parse the corresponding body's structure error output;
[0336] When the fail callback is executed, it checks whether the request has timed out, handles domain name resolution errors accordingly, and checks the boolean values of the parameters showError and showLoading to determine whether to output the error message and display the loading icon.
[0337] In one embodiment, the request module 3 is specifically used for:
[0338] Import the request.js file, call the requestConfig method, configure the common parameters baseUrl, dealwithToken, and dealwith401, select the 401 handling function by configuring dealwith401, pass in the corresponding parameters of the server's HTTP protocol, execute the code call, and initiate a request to the target mini-program.
[0339] In one implementation, the target mini-program request specifically includes:
[0340] The target mini-program must make at least one of the following requests: GET request, POST request, wx.uploadFile upload interface request, or wx.downloadFile download interface request.
[0341] In one implementation, initiating a request to the target mini-program specifically includes:
[0342] The system uses a fuzzy search to determine if a previous request is currently in progress. If so, it stops the previous request and initiates the current request using the interface with the latest time.
[0343] In one embodiment, the response module 4 is specifically used for:
[0344] The system handles request URL caching and token injection, obtains status codes, and uses the server-side common response logic based on the status codes to obtain the response to the target mini-program request.
[0345] Example 3:
[0346] like Figure 5 As shown, Embodiment 3 of this application provides a computer device, which includes a memory and a processor. The memory stores a computer program. When the processor runs the computer program stored in the memory, the processor executes the applet request extension management method as described in Embodiment 1. This computer device can be the applet request extension management device as described in Embodiment 2.
[0347] The memory is connected to the processor. The memory can be flash memory, read-only memory or other types of memory. The processor can be a central processing unit or a microcontroller.
[0348] Example 4:
[0349] like Figure 6 As shown, Embodiment 4 of this application provides a computer-readable storage medium storing a computer program. When the computer program is run by a processor, it implements the applet request extension management method as described in Embodiment 1.
[0350] The computer-readable storage medium includes volatile or non-volatile, removable or non-removable media implemented in any method or technology for storing information (such as computer-readable instructions, data structures, computer program units, or other data). Computer-readable storage media include, but are not limited to, RAM (Random Access Memory), ROM (Read-Only Memory), EEPROM (Electrically Erasable Programmable Read-Only Memory), flash memory or other memory technologies, CD-ROM (Compact Disc Read-Only Memory), DVD or other optical disc storage, cartridges, magnetic tapes, disk storage or other magnetic storage devices, or any other medium that can be used to store desired information and is accessible to a computer.
[0351] Embodiments 1-4 of this application provide a method, apparatus, and medium for managing extended requests in a mini-program. The client can flexibly send different types of requests through configuration, and the server can avoid writing repetitive code by configuring common response logic, thus avoiding callback hell and Loading and Toast conflicts and anomalies.
[0352] It is understood that the above embodiments are merely exemplary embodiments used to illustrate the principles of this application, and this application is not limited thereto. For those skilled in the art, various modifications and improvements can be made without departing from the spirit and substance of this application, and these modifications and improvements are also considered to be within the scope of protection of this application.
Claims
1. A method for managing extended requests in a mini-program, characterized in that, The method includes: Define a unified management system for request parameter bodies across multiple interfaces, including: using Promise calls to avoid callback hell, using aborts to avoid request conflicts during switching, uniformly encapsulating requests and file uploads, and using timestamps to avoid request caching; Configure the server-side common response logic for the request parameter body, including: configuring Loading and Toast and handling display conflicts; Configure request parameters in the request parameter body to initiate a request to the target mini-program; The response to the target mini-program's request is obtained based on the server-side common response logic.
2. The method according to claim 1, characterized in that, Define a unified management system for request parameter bodies across multiple interfaces, including: using Promise calls to avoid callback hell, using aborts to prevent request conflicts during switching, uniformly encapsulating requests and file uploads, and using timestamps to avoid request caching. Specifically, this includes: Define the public attributes and methods for the request: baseUrl, dealwithToken, and dealwith401. Here, baseUrl represents the public path, dealwithToken represents obtaining the token, and dealwith401 represents the logic for handling 401. Define request parameters abort, type, method, url, data, errorStatus, loadingStatus, and header. Here, abort indicates that the request can be aborted, type indicates the basic request or file upload, method indicates the request method, url indicates the path, data indicates the upload data, errorStatus indicates whether to display an error message, loadingStatus indicates whether to display the loading status, and header indicates common request headers. To avoid callback hell, use `new Promise` to make the `wx.request`, `wx.uploadFile`, and `wx.downloadFile` methods Promise-ify them. Add a timestamp to the URL suffix to avoid caching. `preRequest` stores the previous request. When `abort` is true, calling `preRequest.abort` will abort the request. The `type` value determines whether to call `wx.request`, `wx.uploadFile`, or `wx.downloadFile`.
3. The method according to claim 2, characterized in that, The server-side common response logic for the request parameter body is set as follows: Get the response data statusCode; When the statusCode is 200, Promise.resolve returns data; When the statusCode is 404, output a Toast message indicating a path error. When the statusCode is 401, the passed-in processing function is called; When the statusCode is 500 or other backend-defined errors, parse the corresponding body's structure error output; When the fail callback is executed, it checks whether the request has timed out, handles domain name resolution errors accordingly, and checks the boolean values of the parameters showError and showLoading to determine whether to output the error message and display the loading icon.
4. The method according to claim 3, characterized in that, Configure request parameters in the request parameter body to initiate a request to the target mini-program, specifically including: Import the request.js file, call the requestConfig method, configure the common parameters baseUrl, dealwithToken, and dealwith401, select the 401 handling function by configuring dealwith401, pass in the corresponding parameters of the server's HTTP protocol, execute the code call, and initiate a request to the target mini-program.
5. The method according to claim 4, characterized in that, The target mini-program request specifically includes: The target mini-program must make at least one of the following requests: GET request, POST request, wx.uploadFile upload interface request, or wx.downloadFile download interface request.
6. The method according to claim 4, characterized in that, Initiating a request to the target mini-program specifically includes: The system uses a fuzzy search to determine if a previous request is currently in progress. If so, it stops the previous request and initiates the current request using the interface with the latest time.
7. The method according to claim 4, characterized in that, Obtaining the response to the target mini-program request based on the aforementioned server-side common response logic specifically includes: The system handles request URL caching and token injection, obtains status codes, and uses the server-side common response logic based on the status codes to obtain the response to the target mini-program request.
8. A mini-program request extension management device, characterized in that, The device includes: The definition module is used to define the request parameter body for unified management of multiple interfaces, including defining: using Promise calls to avoid callback hell, avoiding request conflicts during switching through abort, uniformly encapsulating requests and file uploads, and using timestamps to avoid request caching; The settings module, connected to the definition module, is used to set the server-side common response logic of the request parameter body, including setting: Loading and Toast configuration and handling display conflicts; The request module, connected to the settings module, is used to configure request parameters in the request parameter body to initiate a request to the target mini-program. The response module, connected to the request module, is used to obtain the response to the request of the target mini-program based on the server-side common response logic.
9. A computer device, characterized in that, The computer device includes a processor and a memory, the memory storing a computer program. When the processor runs the computer program stored in the memory, the processor executes the applet request extension management method as described in any one of claims 1-7.
10. A computer-readable storage medium, characterized in that, The computer-readable storage medium stores a computer program that, when executed by a processor, implements the applet request extension management method as described in any one of claims 1-7.