A front-end and back-end API synchronization collaboration method and system

Abstract

The application provides a front-end and back-end API synchronous cooperation method and system, which comprises the following steps: a back-end proxy module is used to capture a file change event of a back-end interface code, and the back-end interface code is parsed to obtain application programming interface (API) contract difference data; the back-end proxy module is used to send the API contract difference data to a front-end proxy module through a binary star negotiation bus; the front-end proxy module is used to analyze the API contract difference data, determine whether the API contract difference data needs to be simulated, and if it is determined that the API contract difference data needs to be simulated, send the API contract difference data to an intent sandbox; the intent sandbox is used to simulate the API contract difference data and front-end existing project code, and output simulation results; and the front-end proxy module is used to determine a code negotiation strategy according to the simulation results, and modify the front-end code according to the code negotiation strategy and the API contract difference data.

Description

Technical Field

[0001] This invention relates to the field of code modification technology, and more specifically, to a method and system for front-end and back-end API synchronization and collaboration. Background Technology

[0002] In the current stage of front-end and back-end separation development, the back-end typically generates static API specification files and then uploads them to the platform for public release. The front-end uses code generation tools to generate request code according to the specifications, while simultaneously manually writing and maintaining mock data. When APIs change, both sides communicate manually via instant messaging software. After the back-end updates the code and redraws the documentation, the front-end manually synchronizes the code and mock resources. While large teams can add API checks, they can only perform basic static syntax validation and lack automated repair capabilities.

[0003] This traditional collaboration model suffers from several inherent technical shortcomings: the entire system lacks code-level self-healing capabilities; changes such as renaming or deleting backend fields only update static documents, directly causing frontend compilation errors and undefined runtime values; manual repair costs increase linearly with the number of affected components, and the overall repair cost is the sum of the time spent on component rectification and communication expenses with multiple parties, resulting in significant manpower losses; interface changes rely on manual synchronization of information using instant messaging tools, requiring the team to engage in multiple cross-platform communication interactions, while the manually maintained mock data deviates from the actual business logic, not only increasing communication costs but also generating numerous hidden defects during the integration testing phase, resulting in low overall R&D collaboration efficiency. Summary of the Invention

[0004] The purpose of this invention is to address the shortcomings of the prior art by providing a method and system for front-end and back-end API synchronization and collaboration. This system, through a combination of dual-proxies and intent sandbox hierarchical verification, can automatically capture back-end interface changes, simulate and assess the impact scope as needed, and adaptively select repair solutions. This saves developers a significant amount of manual labor costs associated with comparing interface documents, globally searching and modifying front-end code, and communicating offline to align interface changes.

[0005] To achieve the above objectives, the technical solutions adopted in the embodiments of this application are as follows: In a first aspect, embodiments of this application provide a method for front-end and back-end API synchronization and collaboration, the method comprising: A backend proxy module is used to capture file change events of the backend interface code and parse the backend interface code to obtain application programming interface (API) contract difference data; the API contract difference data is used to record change information of the API interface in the backend interface code. The backend proxy module uses a Gemini negotiation bus to send the API contract difference data to the frontend proxy module. The front-end proxy module is used to analyze the API contract difference data to determine whether it is necessary to simulate the API contract difference data. If it is determined that it is necessary to simulate the API contract difference data, the API contract difference data is sent to the intent sandbox. The intent sandbox is used to simulate the API contract difference data and existing front-end project code, and the simulation results are output. The front-end proxy module determines a code negotiation strategy based on the simulation results, and modifies the front-end code according to the code negotiation strategy and the API contract difference data to adapt to the API interface change information in the back-end interface code.

[0006] In an optional implementation, the step of using a backend proxy module to capture file change events of the backend interface code and parsing the backend interface code to obtain application programming interface (API) contract difference data includes: The backend proxy module is used to call the file monitoring module to capture file change events of the backend interface code and read the changed interface code fragments. The backend proxy module is used to call a preset large language model to analyze the modified interface code snippet and obtain the API contract difference data.

[0007] In an optional implementation, the API contract difference data includes: field change information for at least one API interface and corresponding API intent tag information; the step of using the front-end proxy module to analyze the API contract difference data and determine whether simulation of the API contract difference data is required includes: The front-end proxy module assigns a preset weight to at least one of the API interfaces based on the corresponding API intent tag information and performs cumulative calculation to obtain the total change weight. The front-end proxy module uses the total change weight and a preset threshold to determine whether it is necessary to simulate the API contract difference data.

[0008] In an optional implementation, the step of using the front-end proxy module to determine whether to simulate the API contract difference data based on the total change weight and a preset threshold includes: If it is determined that the total weight of the change is less than or equal to the preset threshold, then it is determined that it is not necessary to simulate the API contract difference data. If it is determined that the total weight of the change is greater than the preset threshold, then it is determined that the API contract difference data needs to be simulated.

[0009] In an optional implementation, the step of employing the front-end proxy module to determine a code negotiation strategy based on the simulation results, and modifying the front-end code based on the code negotiation strategy and the API contract difference data, includes: If the simulation results indicate that no crash has occurred, then the code negotiation strategy is determined to be a front-end self-repair strategy; The front-end proxy module, based on the front-end self-repair strategy, calls the internal code modification module to modify the target fields in the front-end code according to the API contract difference data.

[0010] In an optional implementation, the method further includes: If the target field in the front-end code is modified and the front-end UI strongly depends on the target field, the front-end proxy module generates first reverse contract request data based on the strong dependence on the target field, and sends the first reverse contract request data to the back-end proxy module through the Gemini negotiation bus. The backend proxy module generates a first code patch based on the first reverse contract request data.

[0011] In an optional implementation, the method further includes: If the simulation results indicate a crash, then the code negotiation strategy is determined to be a patch generation strategy. The front-end proxy module generates second reverse contract request data based on the generation patch strategy and the simulation results, and sends the second reverse contract request data to the back-end proxy module through the Gemini negotiation bus. The backend proxy module generates a second code patch based on the second reverse contract request data.

[0012] In an optional implementation, the method further includes: If it is determined that simulation of the API contract difference data is not required, the front-end proxy module calls the internal code modification module to modify the target field in the front-end code according to the API contract difference data.

[0013] In an optional implementation, the method further includes: The front-end proxy module is used to send a confirmation notification of front-end code modification to the development terminal; if the confirmation reply instruction of the front-end code modification is received, the modified front-end code is merged into the existing front-end project code; The backend proxy module sends a confirmation notification for the code patch to the development terminal; if a confirmation reply is received for the code patch, the code patch is merged into the existing backend project code.

[0014] Secondly, this application also provides a front-end and back-end API synchronization and collaboration system, which includes: a back-end proxy module, a Gemini negotiation bus, an intent sandbox, and a front-end proxy module. The backend proxy module is used to capture file change events of the backend interface code and parse the backend interface code to obtain application programming interface (API) contract difference data; the API contract difference data is used to record change information of the API interface in the backend interface code. The backend proxy module is also used to send the API contract difference data to the frontend proxy module via the Gemini negotiation bus; The front-end proxy module is used to analyze the API contract difference data, determine whether the API contract difference data needs to be simulated, and if it is determined that the API contract difference data needs to be simulated, then send the API contract difference data to the intent sandbox. The intent sandbox is used to simulate the API contract difference data and existing front-end project code, and output simulation results. The front-end proxy module is further configured to determine a code negotiation strategy based on the simulation results, and modify the front-end code based on the code negotiation strategy and the API contract difference data to adapt to the API interface change information in the back-end interface code.

[0015] The beneficial effects of this application are: This application provides a method and system for front-end and back-end API synchronization and collaboration. The method includes: using a back-end proxy module to capture file change events of back-end interface code and parsing the back-end interface code to obtain API contract difference data; the API contract difference data is used to record change information of API interfaces in the back-end interface code; using the back-end proxy module to send the API contract difference data to a front-end proxy module through a Gemini negotiation bus; using the front-end proxy module to analyze the API contract difference data and determine whether simulation of the API contract difference data is required; if simulation is required, the API contract difference data is sent to an intent sandbox; using the intent sandbox to simulate the API contract difference data and existing front-end project code, and outputting simulation results; using the front-end proxy module to determine a code negotiation strategy based on the simulation results, and modifying the front-end code according to the code negotiation strategy and the API contract difference data to adapt to the change information of API interfaces in the back-end interface code.

[0016] The method in this application, through the combination of twin-star dual-proxy and intent sandbox hierarchical verification, can automatically capture backend interface changes, simulate and assess the impact scope as needed, and adaptively select repair solutions. This saves developers a significant amount of manual labor costs, such as comparing interface documents, globally searching and modifying frontend code, and communicating offline to align interface changes. It avoids chain failures such as frontend compilation errors and page crashes caused by unauthorized changes to backend interfaces from the source. At the same time, the sandbox isolation simulation mechanism ensures that the official source code will not be accidentally modified by automated operations. Combined with the proxy bypass operation feature, it achieves non-intrusive modification of the original business system and significantly reduces communication overhead during the frontend and backend integration testing phase. Attached Figure Description

[0017] To more clearly illustrate the technical solutions of the embodiments of the present invention, the accompanying drawings used in the embodiments will be briefly introduced below. It should be understood that the following drawings only show some embodiments of the present invention and should not be regarded as a limitation on the scope. For those skilled in the art, other related drawings can be obtained based on these drawings without creative effort.

[0018] Figure 1 One of the flowcharts for a front-end and back-end API synchronization and collaboration method provided in this application embodiment; Figure 2 A second flowchart illustrating a front-end and back-end API synchronization and collaboration method provided in this application embodiment; Figure 3 The third flowchart illustrates a front-end and back-end API synchronization and collaboration method provided in this application embodiment; Figure 4 The fourth flowchart illustrates a front-end and back-end API synchronization and collaboration method provided in this application embodiment; Figure 5 The fifth flowchart illustrates a front-end and back-end API synchronization and collaboration method provided in this application embodiment; Figure 6 A flowchart illustrating a front-end and back-end API synchronization and collaboration method provided in this application embodiment is shown in Figure 6. Figure 7 This is the seventh flowchart illustrating a front-end and back-end API synchronization and collaboration method provided in this application embodiment. Detailed Implementation

[0019] To make the objectives, technical solutions, and advantages of the embodiments of the present invention clearer, the technical solutions of the embodiments of the present invention will be clearly and completely described below with reference to the accompanying drawings. Obviously, the described embodiments are some embodiments of the present invention, but not all embodiments.

[0020] Therefore, the following detailed description of the embodiments of this application provided in the accompanying drawings is not intended to limit the scope of the claimed application, but merely to illustrate selected embodiments of the application. All other embodiments obtained by those skilled in the art based on the embodiments of this application without inventive effort are within the scope of protection of this application.

[0021] In the description of this application, it should be noted that if the terms "upper", "lower", etc. appear to indicate the orientation or positional relationship based on the orientation or positional relationship shown in the accompanying drawings, or the orientation or positional relationship that the product of this application is usually placed in, it is only for the convenience of describing this application and simplifying the description, and does not indicate or imply that the device or element referred to must have a specific orientation, or be constructed and operated in a specific orientation, and therefore should not be construed as a limitation of this application.

[0022] Furthermore, the terms "first," "second," etc., used in the specification, claims, and accompanying drawings of this invention are used to distinguish similar objects and are not necessarily used to describe a specific order or sequence. It should be understood that such data can be interchanged where appropriate so that embodiments of the invention described herein can be implemented in orders other than those illustrated or described herein. Additionally, the terms "comprising" and "having," and any variations thereof, are intended to cover a non-exclusive inclusion; for example, a process, method, system, product, or apparatus that comprises a series of steps or units is not necessarily limited to those steps or units explicitly listed, but may include other steps or units not explicitly listed or inherent to such processes, methods, products, or apparatus.

[0023] It should be noted that, where there is no conflict, the features in the embodiments of this application can be combined with each other.

[0024] To reduce communication overhead between the front-end and back-end for API interfaces during the integration testing phase, this application provides a front-end and back-end API synchronization and collaboration system, which includes: a back-end proxy module, a Gemini negotiation bus, an intent sandbox, and a front-end proxy module.

[0025] The backend proxy module is used to capture file change events of the backend interface code and parse the backend interface code to obtain Application Programming Interface (API) contract difference data; the API contract difference data is used to record the change information of the API interface in the backend interface code.

[0026] The backend proxy module is also used to send API contract difference data to the frontend proxy module via the Gemini negotiation bus.

[0027] The front-end proxy module is used to analyze API contract discrepancy data, determine whether it is necessary to simulate the API contract discrepancy data, and if it is determined that it is necessary to simulate the API contract discrepancy data, then send the API contract discrepancy data to the intent sandbox.

[0028] The intent sandbox is used to simulate API contract difference data and existing front-end project code, and output simulation results.

[0029] The front-end proxy module is also used to determine the code negotiation strategy based on the simulation results, and modify the front-end code according to the code negotiation strategy and API contract difference data to adapt to the API interface change information in the back-end interface code.

[0030] The backend proxy module consists of B-Agent, an agent machine instantiated from OpenClaw, an autonomous AI virtual assistant framework licensed by the Massachusetts Institute of Technology (MIT), running in the backend development environment. B-Agent is deployed as a side-channel process on the local workstations of backend developers and does not intrude on the original backend business logic code. Similarly, the frontend proxy module is F-Agent, an agent machine instantiated from OpenClaw in the frontend environment.

[0031] OpenClaw is an open-source, autonomous AI virtual assistant framework. This framework supports multi-channel interaction, autonomous task decomposition, and custom skill extensions, serving as the underlying driving engine for independent front-end / back-end proxy nodes.

[0032] The Twin-Bus negotiation bus adopts a Twin-Agent Architecture, which refers to two interconnected OpenClaw instantiated agents (i.e., the F-Agent front-end agent module and the B-Agent back-end agent module) deployed in the front-end development environment and the back-end development environment respectively. This allows the front-end agent module and the back-end agent module to communicate autonomously and negotiate code state through a dedicated protocol.

[0033] The Intent Sandbox is an isolated virtual testing environment scheduled by OpenClaw. Before the agent officially modifies the front-end and back-end project source code, simulated API changes and front-end component rendering impact tests are performed in this sandbox.

[0034] This system, through a combination of dual-proxies and intent sandbox hierarchical verification, can automatically capture backend interface changes, simulate and assess the impact scope as needed, and adaptively select repair solutions. This saves developers a significant amount of manual labor costs associated with comparing interface documents, globally searching and modifying frontend code, and communicating offline to align interface changes. It avoids chain failures such as frontend compilation errors and page crashes caused by unauthorized changes to backend interfaces from the source. At the same time, the sandbox isolation simulation mechanism ensures that the official source code will not be accidentally modified by automated operations. Combined with the proxy bypass operation feature, it achieves non-intrusive modification of the original business system, significantly reducing the cost of troubleshooting and communication during the frontend and backend integration testing phase.

[0035] This application also provides a method for front-end and back-end API synchronization and collaboration. The following detailed explanation of the method for front-end and back-end API synchronization and collaboration provided by this application is given in conjunction with the accompanying drawings and specific examples. Figure 1 This is one of the flowcharts illustrating a front-end and back-end API synchronization and collaboration method provided in an embodiment of this application. Figure 1 As shown, the method includes: S101. Use the backend proxy module to capture file change events of the backend interface code, and parse the backend interface code to obtain API contract difference data.

[0036] Among them, API contract difference data is used to record changes to API interfaces in the backend interface code.

[0037] In this embodiment, the backend proxy module captures file change events of the backend interface code in real time. If the backend developer modifies the interface code on their terminal and saves it, the backend proxy module can capture the file change event and parse the captured backend interface code to obtain API contract difference data.

[0038] For example, a backend developer edits and saves the user profile interface controller code in the e-commerce user center module, renaming the `age` numeric field returned by the interface to `birthYear` and deleting the `nickName` field, which is strongly dependent on by the frontend. At this time, the backend agent module B-Agent captures this file change event, parses the modified backend interface code, and finally outputs a structured, standardized Diff JSON format API contract difference data. The data records all change information, including the interface address, the change level (BREAKING), the specific change behaviors (renaming and deletion of fields), and the data types of the fields.

[0039] S102. The backend proxy module sends the API contract difference data to the frontend proxy module through the Gemini negotiation bus.

[0040] Specifically, the Twin-Bus is a bidirectional state negotiation communication channel. The underlying layer uses WebSocket network sockets in combination with a custom binary protocol to complete local area network data transmission. The high-performance remote procedure call protocol (Google Remote Procedure Call, GRPC) can also be used as an alternative communication carrier.

[0041] After obtaining the API contract difference data, the backend agent module B-Agent synchronously attaches API intent tag information for this change.<Type: API_BREAKING_CHANGE> The label is used to identify the level of damage caused by this interface change; then the API contract difference data and intent label are encapsulated together into a transmission message and pushed to the front-end agent module F-Agent deployed in the front-end environment via the Twin-Bus negotiation bus.

[0042] After receiving the message, the front-end agent module F-Agent immediately sends a receipt confirmation message back to the back-end agent module B-Agent. At the same time, it sends its current front-end contract state summary back to B-Agent. The lightweight contract state machines on both ends synchronously complete version comparison and conflict self-check. The entire bidirectional send and receive confirmation process has a stable overall transmission latency of less than 200ms in the local area network environment. Unlike the traditional message queue one-way push mechanism, it builds a closed-loop communication link for bidirectional interaction between agents.

[0043] S103. Use the front-end proxy module to analyze the API contract difference data to determine whether it is necessary to simulate the API contract difference data. If it is determined that it is necessary to simulate the API contract difference data, send the API contract difference data to the intent sandbox.

[0044] Specifically, the front-end agent module F-Agent extracts API contract difference data from the message and analyzes it to determine whether simulation of the API contract difference data is necessary. If simulation is required, the API contract difference data is stored in the Intent Sandbox for simulation execution.

[0045] The Intent Sandbox is an isolated virtual testing environment that is uniformly scheduled and managed by OpenClaw. Its runtime resources are physically isolated from the official front-end runtime environment, so it will not interfere with the runtime of the developer's official project.

[0046] S104. Use the intent sandbox to simulate the API contract difference data and the existing front-end project code, and output the simulation results.

[0047] Among them, the front-end agent module F-Agent loads all the code of the existing front-end project along with API contract difference data into an isolated intent sandbox environment.

[0048] The intent is to simulate the mounting of real browser components and the logic of API request calls within the sandbox, and to simulate server response messages using the modified API return data, and to iterate through all business components in the project that reference the user information API.

[0049] For example, the simulation process sequentially verifies the code execution logic of seven business components, including UserProfile.tsx, UserCard.tsx, and the System Settings page. It accurately captures two types of runtime crashes: failure to read the data.age field and rendering errors in the data.nickName field. The intent sandbox integrates all anomalies and a list of affected components to generate an explosion radius impact report. It also synchronously outputs a complete simulation error stack log as the final simulation result data and sends it back to the front-end agent module F-Agent.

[0050] It should be noted that the intent sandbox runs entirely in an isolated virtual environment, and all code simulation behaviors will not modify the local official front-end source code files, ensuring the data security of the official project code.

[0051] S105. The front-end proxy module determines the code negotiation strategy based on the simulation results, and modifies the front-end code according to the code negotiation strategy and API contract difference data to adapt to the API interface change information in the back-end interface code.

[0052] Specifically, the front-end agent module F-Agent determines the code negotiation strategy based on the simulation results. If the code negotiation strategy is determined to be the front-end self-repair strategy, it directly calls its own internal code modification module Skill to perform front-end adaptation modification work and generate front-end code patch files.

[0053] For example, regarding the change of renaming the age field to birthYear, the system automatically retrieves all business code lines in the front-end TypeScript code that read data.age, and rewrites them in batches to the compatible fallback form data.birthYear??data.age. It prioritizes reading the value of the new field from the back-end, using the original field as a fallback compatibility logic. Simultaneously, it automatically modifies the project's global TypeScript interface type definition file and updates the type declarations of the fields returned by the interface.

[0054] In summary, this application provides a front-end and back-end API synchronization and collaboration method. The method includes: using a back-end proxy module to capture file change events in the back-end interface code and parsing the back-end interface code to obtain API contract difference data; the API contract difference data is used to record change information of API interfaces in the back-end interface code; using the back-end proxy module to send the API contract difference data to the front-end proxy module via a Gemini negotiation bus; using the front-end proxy module to analyze the API contract difference data and determine whether simulation of the API contract difference data is required; if simulation is required, the API contract difference data is sent to an intent sandbox; using the intent sandbox to simulate the API contract difference data and existing front-end project code, and outputting simulation results; using the front-end proxy module to determine a code negotiation strategy based on the simulation results, and modifying the front-end code according to the code negotiation strategy and the API contract difference data to adapt to the change information of API interfaces in the back-end interface code.

[0055] The method in this application, through the combination of twin-star dual-proxy and intent sandbox hierarchical verification, can automatically capture backend interface changes, simulate and assess the impact scope as needed, and adaptively select repair solutions. This saves developers a significant amount of manual labor costs, such as comparing interface documents, globally searching and modifying frontend code, and communicating offline to align interface changes. It avoids chain failures such as frontend compilation errors and page crashes caused by unauthorized changes to backend interfaces from the source. At the same time, the sandbox isolation simulation mechanism ensures that the official source code will not be accidentally modified by automated operations. Combined with the proxy bypass operation feature, it achieves non-intrusive modification of the original business system and significantly reduces communication overhead during the frontend and backend integration testing phase.

[0056] Based on the above embodiments, this application also provides another possible implementation of the front-end and back-end API synchronization and collaboration method. Figure 2 This is a second flowchart illustrating a front-end and back-end API synchronization and collaboration method provided in an embodiment of this application; as shown below. Figure 2 As shown, a backend proxy module is used to capture file change events in the backend interface code and parse the backend interface code to obtain API contract difference data, including: S201. The backend proxy module calls the file monitoring module to capture file change events in the backend interface code and read the changed interface code snippet.

[0057] In this embodiment, the file monitoring module is a standardized Skill plugin encapsulated by the OpenClaw framework. After the backend agent module B-Agent starts, it monitors the backend project's resources and controller business directories in real time, and captures and monitors file saving and overwriting behaviors in real time.

[0058] When the backend developers complete the modification of the user profile interface controller code and execute the save command, the file monitoring module immediately captures the file system write change event, locks the path of the modified controller source code file, reads the code snapshot before and after the modification, extracts the changed interface code fragment and passes it to the parsing module of the backend agent module B-Agent, and compiles it to generate the corresponding Abstract Syntax Tree (AST) structure.

[0059] S202. The backend proxy module is used to call the preset large language model to analyze the changed interface code snippets and obtain API contract difference data.

[0060] The backend agent module B-Agent has a built-in, flexibly configurable general large model calling interface, which can call preset large language modules, such as DeepSeek and GPT. There is no need to carry out domain-specific model training. Code change recognition can be completed by relying on fixed structured parsing prompt words.

[0061] Specifically, the backend agent module B-Agent encapsulates the intercepted modified interface code snippet and the original baseline code snippet into a prompt word template and sends it to the preset large language model. The preset large language model is required to identify the interface address, HTTP request method, addition / deletion / renaming / type modification behavior of the returned field, and the level of destructiveness of the change. The preset large language model outputs the parsed content according to the preset JSON format specification, and obtains standardized API contract difference data with a unified format that can be recognized and parsed by F-Agent. For example, the API contract difference data includes: identifying that the age field in the return value has been renamed to user_age.

[0062] In the method provided in this application embodiment, the real interface code change fragments are captured by the backend proxy module, and standardized API contract difference data can be generated by combining it with a general preset large language model. This can unify the data interaction standards of the front-end and back-end proxies, avoid the problem of omissions and errors in manually sorting interface change information, and improve the accuracy and standardization of interface change data extraction.

[0063] This application also provides another possible implementation of the front-end and back-end API synchronization and collaboration method. The API contract difference data includes: field change information of at least one API interface and corresponding API intent tag information. Figure 3 This is the third flowchart illustrating a front-end and back-end API synchronization and collaboration method provided in this application embodiment; as shown below. Figure 3 As shown, a front-end proxy module is used to analyze API contract discrepancy data to determine whether simulation of the API contract discrepancy data is necessary, including: S301. The front-end proxy module assigns a preset weight to at least one API interface based on the corresponding API intent tag information and performs cumulative calculation to obtain the total change weight.

[0064] In this embodiment, the front-end agent module F-Agent parses the API intent tags bound in the Twin-Bus transmission messages, uses the percentage of single-field changes to the total number of interface fields as the single-field weight assignment rule, assigns a preset weight to at least one API interface and performs cumulative calculation to obtain the total change weight.

[0065] For example, if the / api / user / profile interface in this case contains a total of 10 returned fields, and there are two field changes in this case, namely the name change of age and the deletion of nickName, the weight of a single field change is 10%. The total weight of the two changes is calculated to be 20% for the overall change of this interface. When there are multiple field changes in the same interface, the number of changed fields is counted one by one, and the weight values ​​of all single fields are accumulated according to the same weight calculation rules to form the total weight value of the complete change of the current interface.

[0066] S302. The front-end proxy module determines whether it is necessary to simulate the API contract difference data based on the total weight of the change and the preset threshold.

[0067] The front-end proxy module determines whether it is necessary to simulate the API contract difference data by comparing the total weight of the change with a preset threshold.

[0068] Optionally, if it is determined that the total weight of the change is less than or equal to a preset threshold, then it is determined that simulation of the API contract difference data is not required.

[0069] If the total weight of the change is determined to be greater than the preset threshold, then it is determined that the API contract difference data needs to be simulated.

[0070] Specifically, if the preset threshold is set to 60%, the front-end agent module F-Agent will compare the total weight of the changes calculated in real time with the preset threshold. When the total weight of the changes is ≤60%, it is determined that the impact of this interface change is small and the damage is low. There is no need to enable the intent sandbox to perform simulation verification. Instead, the front-end code will automatically fix the problem.

[0071] When the total weight of the change is greater than 60%, it is determined that the scope of the interface change is large, which is likely to cause large-scale compilation and runtime errors on the front end. It is necessary to send the API contract difference data into the intent sandbox to complete the simulation verification of the impact on all project components, and select the matching code self-healing negotiation strategy based on the simulation results.

[0072] The method provided in this application embodiment quantifies the total weight of changes by the proportion of the number of changed fields and compares it with a preset threshold. This enables intelligent on-demand start and stop of the sandbox simulation process. Minor field changes can skip the simulation process and perform rapid repairs directly, while high-risk, large-scale interface changes are forced to enter the sandbox for verification. This balances the efficiency of interface adaptation and repair while controlling the operational risks of high-risk changes. It avoids resource redundancy and increased processing latency caused by performing simulations for all changes, and also avoids online risks caused by directly modifying code while ignoring major interface changes. This balances the efficiency and security of automated repair.

[0073] This application also provides another possible implementation of the front-end and back-end API synchronization and collaboration method. Figure 4 This is the fourth flowchart illustrating a front-end and back-end API synchronization and collaboration method provided in this application embodiment; as shown below. Figure 4 As shown, the front-end proxy module determines the code negotiation strategy based on the simulation results, and modifies the front-end code according to the code negotiation strategy and API contract difference data, including: S401. If the simulation results indicate that no crash has occurred, then the code negotiation strategy is determined to be the front-end self-repair strategy.

[0074] In this embodiment, once it is determined that API contract difference data needs to be simulated, the intent sandbox simulates the API contract difference data and the existing front-end project code, and outputs the simulation results. The simulation results include simulation logs, impact surface reports, information such as whether page rendering crashes occurred, whether interface reading errors occurred, and whether compilation was abnormal.

[0075] If the simulation results include no page rendering crashes, interface reading errors, compilation exceptions, or other issues in the impact report, then the simulation results indicate that no crashes have occurred. In this case, the front-end agent module F-Agent determines that the current back-end interface changes only involve minor modifications to the field compatibility classes. The front-end can complete the full adaptation by rewriting its own code without needing to engage in reverse negotiation with the back-end agent. Therefore, the code negotiation strategy is determined to be the front-end self-repair strategy.

[0076] S402. The front-end proxy module is used to modify the target fields in the front-end code based on the front-end self-repair strategy by calling the internal code modification module and modifying them according to the API contract difference data.

[0077] The code modification module is a code editing skill component encapsulated by OpenClaw, which has the ability to search for code, rewrite syntax, and synchronize and update TypeScript (TS) type files.

[0078] Specifically, the front-end proxy module, based on the front-end self-repair strategy, calls the internal code modification module to globally search the reference code of the corresponding old fields in all JSX, TS, and TSX files within the Vue / React project according to the field change details recorded in the API contract difference data. It configures the new and old field compatibility reading logic for renamed fields, synchronously corrects the interface type definition files within the project, and adds code comment markers and fallback null value handling logic to deleted fields. All code modification operations generate independent code difference patch files, which do not directly overwrite the original source code. They are only written into the official project files after being confirmed by the developers, ensuring the security of the original source code data.

[0079] In the method provided in this application embodiment, a front-end self-repair strategy is adopted when the simulation result indicates that no crash has occurred. By using built-in code modification skills, field compatibility fallback logic is automatically generated and TS type definition files are modified simultaneously. Front-end adaptation and compatibility can be completed without back-end code modification. Contract synchronization adaptation is completed in the lightest modification way, reducing the amount of code modification on both ends, reducing code redundancy, and all modifications are retained in the form of patches, which makes it convenient for developers to trace and view the changes. It is suitable for high-frequency, small-scale interface iteration scenarios in daily development and effectively improves the self-healing speed of routine interface changes.

[0080] This application also provides another possible implementation of the front-end and back-end API synchronization and collaboration method. Figure 5 This is the fifth flowchart illustrating a front-end and back-end API synchronization and collaboration method provided in this application embodiment; as shown below. Figure 5 As shown, the method also includes: S501. If the target field in the front-end code is modified and the front-end UI becomes strongly dependent on the target field, the front-end proxy module generates the first reverse contract request data based on the strong dependency on the target field, and sends the first reverse contract request data to the back-end proxy module through the Gemini negotiation bus.

[0081] In this embodiment, after modifying the target field in the front-end code, a situation arises where the front-end UI strongly depends on the target field. For example, the nickName field is completely deleted by the back-end. Multiple UI interfaces on the front-end, such as the personal profile card, user avatar display module, and personal nickname settings page, rigidly read the nickName field to render and display data. Even if the front-end adds null values ​​as a fallback logic, it will still cause blank display and style disorder issues. This is determined to be a case where the front-end UI strongly depends on the deleted field.

[0082] At this point, the front-end agent module F-Agent identifies the strong dependency scenario, encapsulates and generates the first reverse contract request data, and marks the target interface address, the names of the fields that need to be retained in the back-end output, the field data format, and the compatibility time requirements, etc., and transmits it to the back-end agent module B-Agent through the Twin-Bus bidirectional protocol channel to initiate an interface backward compatibility adaptation request to the back-end.

[0083] S502, The backend proxy module generates the first code patch based on the first reverse contract request data.

[0084] Specifically, after the backend agent module B-Agent receives the first reverse contract request data, it locates the backend interface response assembly code, automatically adds an interface compatibility adapter layer code to the outside of the original business interface, and generates an independent code patch file.

[0085] This adapter layer, while ensuring the API returns the new fullName field, synchronously maps and assigns data to the nickName field. It extracts the corresponding nickname data from the fullName field and fills it back into the original nickName return parameter. This allows the API to return both the old and new sets of field parameters simultaneously, providing a backward-compatible API output format to the front end. The patch file is independent of the original business code and will not tamper with the original main business logic code.

[0086] In the method provided in this application embodiment, when the front-end UI has a strong dependency on the deleted interface field, the front-end proxy module actively sends the first reverse contract request data to the back-end proxy module, and the back-end proxy module automatically generates a compatibility adapter code patch. There is no need for front-end and back-end developers to communicate and negotiate compatibility solutions offline. The adapter exists independently of the original business code and will not tamper with the core business logic. The interface is backward compatible while retaining the original front-end page display logic without major reconstruction. This solves the problems of blank front-end interface and style disorder caused by hard deletion of fields, and takes into account the stability of business use and the freedom of back-end code iteration.

[0087] This application also provides another possible implementation of the front-end and back-end API synchronization and collaboration method. Figure 6 This is a flowchart illustrating a front-end and back-end API synchronization and collaboration method provided in an embodiment of this application; as shown in Figure 6. Figure 6 As shown, the method also includes: S601. If the simulation results indicate a crash, then the code negotiation strategy is determined to be the patch generation strategy.

[0088] In this embodiment, if the simulation results include multiple front-end component rendering crashes, page loading failures, compilation errors, and other abnormal issues, the simulation results indicate that a crash has occurred, meaning that simply modifying the front-end code cannot complete the business adaptation. At this time, the front-end agent module F-Agent selects the back-end patch generation strategy, terminates the simple front-end self-repair process, and starts the two-end agent contract negotiation mechanism.

[0089] S602. The front-end proxy module uses a patch generation strategy to generate second reverse contract request data based on simulation results, and sends the second reverse contract request data to the back-end proxy module through the Gemini negotiation bus.

[0090] Specifically, the front-end agent module F-Agent combines the simulation results, including the list of crash points, the scope of affected components, and detailed interface change data output by the intent sandbox, to compile a second reverse contract request data. This second reverse contract request data records all changed fields that caused the front-end crash, the corresponding front-end business modules, specific interface compatibility requirements, data type constraints, and other information. The second reverse contract request data, along with a unique negotiation serial number, is sent to the back-end agent module B-Agent via the Twin-Bus negotiation bus. Simultaneously, it waits for the back-end agent to return patch generation receipt information, completing the distribution of the front-end negotiation request.

[0091] S603: The backend proxy module generates a second code patch based on the second reverse contract request data.

[0092] Specifically, the backend proxy module B-Agent parses all compatibility requirements within the second reverse contract request data, builds a unified compatibility adapter layer in batches on the corresponding backend interface links, configures data compatibility mapping rules in batches for renaming and deleting fields, and generates standardized backend Adapter code patch files. The patch files include modification instructions, a list of adapted fields, and version numbers, allowing backend developers to intuitively view the changes.

[0093] In the method provided in this application embodiment, when the simulation result indicates a crash, the backend patch generation strategy is directly activated. Based on the actual crash point obtained from the simulation, a second reverse contract request data is generated. The backend proxy module develops an adapter patch according to the request. Compared with blindly modifying the entire frontend code, this method can accurately locate the root cause of the fault and complete cross-end collaborative repair. Even under large-scale destructive interface changes, it can still achieve automated contract self-healing, greatly reducing the probability of system failure caused by destructive API iteration and shortening the manual repair cycle after large-scale errors.

[0094] This application also provides another possible implementation of a front-end and back-end API synchronization and collaboration method, which further includes: If it is determined that simulation of API contract difference data is not required, the front-end proxy module calls the internal code modification module to modify the target fields in the front-end code based on the API contract difference data.

[0095] In this embodiment, if the total weight of the change is less than or equal to a preset threshold, it is determined that there is no need to simulate the API contract difference data. At this time, the front-end agent module F-Agent directly calls the built-in code modification module to read the API contract difference data, and completes a series of adaptation operations such as front-end code field compatibility rewriting, TS interface definition update, and obsolete field annotation in batches. Simultaneously, a front-end code change patch file is generated, and the interface change adaptation work is completed in a lightweight manner, shortening the execution time of the overall code self-healing and adapting to the development scenario of high-frequency small-scale interface field adjustments during the development process.

[0096] In the method provided in this application embodiment, if it is determined that there is no need to simulate API contract difference data, the front-end code modification logic is executed by bypassing sandbox simulation, the interface adaptation work is completed in a lightweight manner, and the frequent minor field adjustment needs during the development process are matched. Under the premise of ensuring the compatibility and correctness of the basic code, the response speed of automated repair is further improved, and the smoothness of local iteration for developers is optimized.

[0097] This application also provides another possible implementation of the front-end and back-end API synchronization and collaboration method. Figure 7 This is the seventh flowchart illustrating a front-end and back-end API synchronization and collaboration method provided in this application embodiment; as shown below. Figure 7 As shown, the method also includes: S701: Use the front-end proxy module to send a confirmation notification of front-end code modification to the development terminal; if a confirmation reply instruction for front-end code modification is received, merge the modified front-end code into the existing front-end project code.

[0098] In this embodiment, after the front-end agent module F-Agent completes the front-end code modification and generates the code patch file, it pushes a pop-up confirmation notification to the sidebar of the editor on the developer's development terminal, relying on the multi-channel interaction capabilities supported by the OpenClaw framework. It can also optionally be used with instant messaging channels to push modification details, a list of affected files, and a preview of code differences.

[0099] After the developers confirm that the patch content is correct, they click the confirmation button on the interface to send a confirmation reply command. After receiving the confirmation command, the front-end agent module F-Agent merges the modified front-end code in the code patch file into the local source code file of the front-end project. The entire process of code entry into the database is manually controlled to avoid unexpected code changes caused by automated modifications.

[0100] S702: Use the backend proxy module to send a confirmation notification for the code patch to the development terminal; if a confirmation reply instruction for the code patch is received, merge the code patch into the existing backend project code.

[0101] Specifically, after the backend agent module B-Agent generates the backend adapter code patch file, it synchronously pushes a patch confirmation reminder to the workspace of the development terminal held by the backend developers, displaying details of the newly added code in the Adapter layer and an explanation of the interface compatibility logic.

[0102] After the backend developers verify that the adapter code does not affect the original business logic, they click to confirm the approval instruction. The backend agent module B-Agent then merges the adapter patch code into the backend project file, completing the synchronous self-healing implementation of the code on both the frontend and backend.

[0103] In the method provided in this application embodiment, the front-end agent automatically pushes code modification patches to the developer's terminal for manual confirmation and approval. Automated modifications are not directly written into the official project source code; the authority to merge the code into the repository is controlled manually. This avoids potential problems such as syntax errors and business logic deviations caused by AI-automated code rewriting. While enjoying the efficiency advantages of automated repair, it retains the manual verification fallback mechanism, balancing development efficiency and the security and controllability of project code. Similarly, the back-end adapter patch is pushed for manual review before code merging. This achieves automated generation of back-end compatible code, while allowing developers to control the timing and rationality of patch implementation. The entire front-end and back-end code self-healing process is ultimately closed by manual confirmation. This replaces the traditional human-to-human joint debugging mode with a new collaborative mode of autonomous negotiation between agents and manual review. It can significantly reduce the error rate of joint debugging caused by API changes, and the overall architecture is deployed as a bypass process, so it will not intrude on the original front-end and back-end projects throughout the process, resulting in lower deployment and integration costs.

[0104] The above are merely specific embodiments of the present invention, but the scope of protection of the present invention is not limited thereto. Any variations or substitutions that can be easily conceived by those skilled in the art within the technical scope disclosed in the present invention should be included within the scope of protection of the present invention. Therefore, the scope of protection of the present invention should be determined by the scope of the claims.

Claims

1. A method for front-end and back-end API synchronization and collaboration, characterized in that, The method includes: A backend proxy module is used to capture file change events of the backend interface code and parse the backend interface code to obtain application programming interface (API) contract difference data; the API contract difference data is used to record change information of the API interface in the backend interface code. The backend proxy module uses a Gemini negotiation bus to send the API contract difference data to the frontend proxy module. The front-end proxy module is used to analyze the API contract difference data to determine whether it is necessary to simulate the API contract difference data. If it is determined that it is necessary to simulate the API contract difference data, the API contract difference data is sent to the intent sandbox. The intent sandbox is used to simulate the API contract difference data and existing front-end project code, and the simulation results are output. The front-end proxy module determines a code negotiation strategy based on the simulation results, and modifies the front-end code according to the code negotiation strategy and the API contract difference data to adapt to the API interface change information in the back-end interface code.

2. The method according to claim 1, characterized in that, The method involves using a backend proxy module to capture file change events in the backend interface code and parsing the backend interface code to obtain application programming interface (API) contract difference data, including: The backend proxy module is used to call the file monitoring module to capture file change events of the backend interface code and read the changed interface code fragments. The backend proxy module is used to call a preset large language model to analyze the modified interface code snippet and obtain the API contract difference data.

3. The method according to claim 1, characterized in that, The API contract difference data includes: field change information for at least one API interface and corresponding API intent tag information; the step of using the front-end proxy module to analyze the API contract difference data and determine whether simulation of the API contract difference data is necessary includes: The front-end proxy module assigns a preset weight to at least one of the API interfaces based on the corresponding API intent tag information and performs cumulative calculation to obtain the total change weight. The front-end proxy module uses the total change weight and a preset threshold to determine whether it is necessary to simulate the API contract difference data.

4. The method according to claim 3, characterized in that, The step of using the front-end proxy module to determine whether to simulate the API contract difference data based on the total change weight and a preset threshold includes: If it is determined that the total weight of the change is less than or equal to the preset threshold, then it is determined that it is not necessary to simulate the API contract difference data. If it is determined that the total weight of the change is greater than the preset threshold, then it is determined that the API contract difference data needs to be simulated.

5. The method according to claim 1, characterized in that, The step involves the front-end proxy module determining a code negotiation strategy based on the simulation results, and modifying the front-end code according to the code negotiation strategy and the API contract difference data, including: If the simulation results indicate that no crash has occurred, then the code negotiation strategy is determined to be a front-end self-repair strategy; The front-end proxy module, based on the front-end self-repair strategy, calls the internal code modification module to modify the target fields in the front-end code according to the API contract difference data.

6. The method according to claim 5, characterized in that, The method further includes: If the target field in the front-end code is modified and the front-end UI strongly depends on the target field, the front-end proxy module generates first reverse contract request data based on the strong dependence on the target field, and sends the first reverse contract request data to the back-end proxy module through the Gemini negotiation bus. The backend proxy module generates a first code patch based on the first reverse contract request data.

7. The method according to claim 1, characterized in that, The method further includes: If the simulation results indicate a crash, then the code negotiation strategy is determined to be a patch generation strategy. The front-end proxy module generates second reverse contract request data based on the generation patch strategy and the simulation results, and sends the second reverse contract request data to the back-end proxy module through the Gemini negotiation bus. The backend proxy module generates a second code patch based on the second reverse contract request data.

8. The method according to claim 1, characterized in that, The method further includes: If it is determined that simulation of the API contract difference data is not required, the front-end proxy module calls the internal code modification module to modify the target field in the front-end code according to the API contract difference data.

9. The method according to claim 1, characterized in that, The method further includes: The front-end proxy module is used to send a confirmation notification of front-end code modification to the development terminal; if the confirmation reply instruction of the front-end code modification is received, the modified front-end code is merged into the existing front-end project code; The backend proxy module sends a confirmation notification for the code patch to the development terminal; if a confirmation reply is received for the code patch, the code patch is merged into the existing backend project code.

10. A front-end and back-end API synchronization and collaboration system, characterized in that, The front-end and back-end API synchronization and collaboration system includes: a back-end proxy module, a Gemini negotiation bus, an intent sandbox, and a front-end proxy module; The backend proxy module is used to capture file change events of the backend interface code and parse the backend interface code to obtain application programming interface (API) contract difference data; the API contract difference data is used to record change information of the API interface in the backend interface code. The backend proxy module is also used to send the API contract difference data to the frontend proxy module via the Gemini negotiation bus; The front-end proxy module is used to analyze the API contract difference data, determine whether the API contract difference data needs to be simulated, and if it is determined that the API contract difference data needs to be simulated, then send the API contract difference data to the intent sandbox. The intent sandbox is used to simulate the API contract difference data and existing front-end project code, and output simulation results. The front-end proxy module is further configured to determine a code negotiation strategy based on the simulation results, and modify the front-end code based on the code negotiation strategy and the API contract difference data to adapt to the API interface change information in the back-end interface code.

Images