Interface compatible conversion method, electronic device, storage medium and computer program product

Abstract

Embodiments of the present application relate to an interface compatible conversion method, electronic equipment, storage medium and computer program product. The method comprises: collecting new and old interface definitions, historical traffic, call chains and field access events, constructing a field semantic constraint graph containing old / new field nodes, consumer nodes and reading, version replacement, unit conversion, enumeration correspondence, derivation and common constraint edges; accordingly, a candidate mapping with confidence, field path, conversion prompt, applicable version and evidence is generated; high-confidence candidates are compiled into deterministic compatibility rules composed of predefined action primitives, which can be statically verified; then, according to the historical traffic, the old and new interface path shadow playback is performed respectively, and the semantic consistency is compared to determine whether to publish. Through the fusion of real consumption evidence and field semantics, the application generates auditable compatible rules, reduces silent errors through static verification and shadow playback, and thus realizes the safe publication of interface deterministic compatible rules.

Description

Technical Field

[0001] This application relates to the field of application programming interface (API) technology, and in particular to an interface compatibility conversion method, electronic device, storage medium, and computer program product. Background Technology

[0002] In microservices, mobile applications, and multi-platform collaborative systems, interface providers and consumers typically iterate independently. The same field may be renamed, split, merged, have its unit changed, its enumeration value adjusted, its null semantics altered, or moved to a new object level in a new version. For example, the old field `amount` might represent "cents," while the new field `totalAmount` represents "yuan"; or the old state value `PAID` might be split into `PAYMENT_CONFIRMED` and `SETTLED` in a new version. Simply comparing field names and declaration types is insufficient to determine whether these changes preserve business semantics.

[0003] Existing interface compatibility checking solutions mainly rely on schema file differences, field existence, type convertibility, and manually maintained adaptation code. Such solutions typically do not know whether a field is read by a real client, what calculation it participates in after being read, or whether it satisfies business invariants together with other fields. They also cannot identify cases where "the names are different but the meanings are the same" or "the names are the same but the units or enumeration meanings have changed."

[0004] Some systems employ generative artificial intelligence to automatically generate adaptation code based on API documentation or field names. Because the model output may lack real-world operational evidence, implicit unit conversions, null value handling, or rollback conditions, directly executing the generated code may produce silent data errors. Silent errors may not necessarily lead to API errors, but they could cause the client to display incorrect amounts, time offsets, incorrect status judgments, or trigger incorrect business branches.

[0005] Traditional regression testing typically uses pre-written, fixed test cases, which struggle to cover long-tail field combinations, older client versions, canary deployments, and cross-service call paths in production traffic. Even if the JSON structures returned by the old and new interfaces are similar, it cannot prove that the client's final read values, cross-field constraints, and degradation behavior are consistent. Summary of the Invention

[0006] To address the aforementioned issues, embodiments of this application provide an interface compatibility conversion method, an electronic device, a storage medium, and a computer program product.

[0007] According to a first aspect of the embodiments of this application, an interface compatibility conversion method is provided, the method comprising: A field semantic constraint graph is constructed based on the collected target information. The target information includes the new version definition information, old version definition information, historical request and response, distributed call chain, and field access events at runtime of the target interface. The field access events record at least the complete hierarchical path of the field being read, the consumer identifier and corresponding version that initiated the read, and the type of operation performed on the field at runtime. The nodes of the field semantic constraint graph include the old field nodes, new field nodes, and consumer nodes of the target interface. The consumer node represents the consumer entity that actually reads the field at runtime and its corresponding version. The edges of the field semantic constraint graph include edges used to represent actual reading, version substitution, unit conversion, enumeration correspondence, derived calculation, or common constraint relationships between nodes. One or more candidate field mappings are generated based on the field semantic constraint graph. Each candidate field mapping includes a confidence score, the corresponding field path in the old version definition information and the new version definition information, and also includes one or more of the following: conversion action prompt, applicable version range, and evidence reference. Candidate fields with confidence scores greater than a first preset threshold are mapped and compiled into deterministic compatibility rules. The deterministic compatibility rules consist of predefined action primitives of the target interface and are used to perform static security checks. Based on historical traffic samples, the first shadow playback of the target interface based on the old interface path and the second shadow playback of the target interface based on the new interface path are executed according to the deterministic compatibility rule, respectively, to compare the semantic consistency of the target interface under the old interface path and the target interface under the new interface path, and to determine whether to publish the deterministic compatibility rule based on the comparison result of the semantic consistency.

[0008] In one implementation, the runtime field access event further includes a tracking identifier, an interface endpoint, a de-identified summary of the field's subsequent usage, and a timestamp. The operation types include reading, null checking, comparison, arithmetic, concatenation, or branching. The runtime field access event is obtained through bytecode instrumentation, compiler plugins, proxy objects, serialization hooks, gateway plugins, data access proxies, or a combination of static analysis and runtime sampling.

[0009] In one implementation, the semantic feature vector of each field node in the field semantic constraint graph includes: The target field declaration type and runtime observation type, the business measurement unit or conversion scale corresponding to the target field, the allowed range or historical observation value range of the target field, the enumeration value set and the business meaning of each enumeration value, whether the target field is allowed to be empty and the default value and empty judgment semantics when missing, the hierarchical path and structural context of the target field, the operation method performed by the real consumer on the target field, the frequency of joint occurrence of the target field with other fields and common constraint relationships, and various semantic descriptions in the interface definition or business document.

[0010] In one implementation, generating one or more candidate field mappings based on the field semantic constraint graph includes: The new and old interface definitions are structurally aligned to generate a set of field changes. The consumers affected by the changes and their corresponding risk levels are located in the set of field changes based on the field semantic constraint graph. The change types of the set of field changes include multiple types such as addition, deletion, renaming, hierarchical movement, type change, unit change, enumeration recoding, splitting, merging, null value semantic change, and default value change. The risk level is obtained based on multiple factors such as consumer importance, read frequency, operation sensitivity, semantic change magnitude, and historical anomaly rate. The field semantic subgraph, pattern difference, field document summary, value distribution summary, and consumer usage summary corresponding to the affected consumers are input into the artificial intelligence model so that the artificial intelligence model outputs one or more candidate field mappings.

[0011] In one implementation, before mapping candidate fields with confidence scores greater than a first preset threshold into deterministic compatibility rules, the method further includes: If the difference between the confidence scores of the candidate field mapping with the highest confidence score and the candidate field mapping with the second highest confidence score is lower than the difference threshold, then the deterministic compatibility rule is manually confirmed without proceeding to the compilation step. The confidence score of the candidate field mapping is obtained from multiple factors including semantic similarity, consumer usage similarity, statistical distribution matching degree, business constraint satisfaction degree, historical support degree, privacy risk, and ambiguity. If the candidate field mapping lacks unit and enumeration evidence, then the deterministic compatibility rule is manually verified without proceeding to the compilation step.

[0012] In one implementation, the deterministic compatibility rule includes multiple elements such as scope of application, source path, target path, preconditions, conversion actions, invariant constraints, fallback actions, validity period, and evidence hash; the scope of application is limited to the interface, service version, consumer version, and traffic bucket; the preconditions are limited to the existence, type, and value range of fields; the predefined action primitives include multiple elements such as path selection, type conversion, unit conversion, enumeration mapping, default value filling, field splitting, field merging, fallback actions, rounding mode, time zone conversion, and condition selection.

[0013] In one implementation, before performing a first shadow replay of the target interface based on the old interface path and a second shadow replay of the target interface based on the new interface path according to the deterministic compatibility rules based on historical traffic samples, to compare the semantic consistency of the target interface under the old interface path and the target interface under the new interface path, the method further includes: In the event of any failure in the static security checks, the deterministic compatibility rule is prevented from entering shadow playback. The static security checks include multiple checks such as type closure, unit dimension consistency, enumeration value coverage integrity, value boundary security, rule circular dependency, rule conflict, and prohibited access fields.

[0014] In one implementation, the step of performing a first shadow replay of the target interface based on the old interface path and a second shadow replay of the target interface based on the new interface path according to the deterministic compatibility rule based on historical traffic samples, to compare the semantic consistency of the target interface under the old interface path and the target interface under the new interface path, and determining whether to publish the deterministic compatibility rule based on the comparison result of the semantic consistency, includes: Select target samples from historical traffic that cover the affected consumers, versions, enumeration values, boundary values, and field combinations. After de-identifying the target samples, perform a first shadow playback of the target interface based on the old interface path and a second shadow playback of the target interface based on the new interface path using the same de-identified sample, and isolate external side effects. Compare the final read value of the target field by the real consumer, the business branch execution summary, and cross-field invariants under the old interface path and the new interface path to determine semantic consistency, and calculate the rule confidence based on the validation pass rate; The deterministic compatibility rule is determined based on the confidence level of the rule, and is either rejected, manually approved, or released in a gray-scale ratio. The released deterministic compatibility rule is revoked when the online semantic deviation index reaches the second preset threshold.

[0015] In one implementation, the desensitization process employs one or more of the following methods: typed placeholders, order-preserving tokens, intervalization, or structured summarization; the external side effects include database writing, message sending, payment operations, and notification sending, which are intercepted or written to isolated storage by a shadow agent; the target sample selection is achieved using one or more of the following methods: coverage optimization, stratified sampling, boundary value generation, cluster center selection, or risk-based active sampling.

[0016] In one implementation, determining semantic consistency includes: Compare whether the target value read by the real consumer is consistent with the old value after semantic normalization; Compare whether the cross-field invariant retention, the default values ​​triggered when a field is missing, and the fallback paths are consistent; Compare the true / false results of key condition judgments, permission decisions, and state machine transitions to see if they are consistent.

[0017] In one implementation, the step of deciding whether to reject, manually approve, or release the deterministic compatibility rule in a gray-scale manner based on the rule confidence level includes: Automatic publishing will be rejected when the rule confidence level is below a first threshold. When the rule confidence level is between the first threshold and the second threshold, manual approval is initiated. When the rule confidence score is higher than the second threshold and all high-risk invariants pass, gray-scale release is permitted, wherein the first threshold is less than the second threshold, and the rule confidence score is obtained from multiple factors including evidence strength, historical sample coverage, replay consistency, key consumer coverage, rule complexity, and ambiguity.

[0018] In one implementation, the grayscale distribution includes: The deterministic compatibility rules are bound to the applicable interface, service version, consumer version, traffic ratio, validity period, and rollback indicators and digitally signed. Only deterministic compatibility rules with valid signatures and matching scope are loaded at the compatibility execution layer; The deterministic compatibility rules are enabled and monitored in stages according to the first percentage, second percentage, third percentage and fourth percentage of matching traffic. The monitoring indicators include multiple indicators such as rule hit rate, conversion failure rate, field missing rate, consumer parsing anomaly, cross-field invariant failure, key business success rate and old version client error rate. The first percentage is less than the second percentage, the second percentage is less than the third percentage and the third percentage is less than the fourth percentage.

[0019] In one embodiment, the method further includes: Write manually confirmed field relationships, static validation results, reasons for replay success or failure, online grayscale metrics, and rollback reasons into the sample database; The candidate ranking model is updated with the final confirmed mapping as the label, and the risk model is updated with the semantic bias and rollback results as the label; Before the new model goes live, it is validated on the interface upgrade records that are later in time, without reducing the recall rate of high-risk changes.

[0020] According to a second aspect of the embodiments of this application, an electronic device is provided, comprising: A memory on which computer programs are stored; A processor for executing the computer program in the memory to implement the steps of the method of any one of the first aspects.

[0021] According to a third aspect of the embodiments of this application, a non-transitory computer-readable storage medium is provided, on which a computer program is stored, which, when executed by a processor, implements the steps of the method described in any one of the first aspects.

[0022] According to a fourth aspect of the embodiments of this application, a computer program product is provided, including a computer program that, when executed by a processor, implements the steps of the method described in any one of the first aspects.

[0023] The embodiments of this application achieve the following beneficial effects: These embodiments collect old and new interface definitions, historical traffic, call chains, and field access events to construct a field semantic constraint graph containing old / new field nodes, consumer nodes, and edges for reading, version replacement, unit conversion, enumeration correspondence, derivation, and common constraint. Based on this, candidate mappings with confidence levels, field paths, conversion hints, applicable versions, and evidence are generated. High-confidence candidates are compiled into deterministic compatibility rules composed of predefined action primitives and capable of static verification. Then, shadow replay of old and new interface paths is performed according to historical traffic, and semantic consistency is compared to determine whether to publish. By integrating real consumption evidence with field semantics, these embodiments generate auditable compatibility rules. Static verification and shadow replay reduce silent errors, thereby achieving secure publishing of interface deterministic compatibility rules.

[0024] Other features and advantages of this application will be described in detail in the following detailed description section. Attached Figure Description

[0025] The accompanying drawings, which are included to provide a further understanding of this application and form part of this application, illustrate exemplary embodiments and are used to explain this application, but do not constitute an undue limitation of this application. In the drawings: Figure 1 This is a flowchart of an interface compatibility conversion method provided in an embodiment of this application.

[0026] Figure 2 This is a flowchart of an interface compatibility conversion method provided in an embodiment of this application.

[0027] Figure 3 This is a flowchart of an interface compatibility conversion method provided in an embodiment of this application.

[0028] Figure 4 This is a flowchart of an interface compatibility conversion method provided in an embodiment of this application.

[0029] Figure 5 This is a flowchart of an interface compatibility conversion method provided in an embodiment of this application.

[0030] Figure 6 This is a flowchart of an interface compatibility conversion method provided in an embodiment of this application.

[0031] Figure 7 This is a flowchart of an interface compatibility conversion method provided in an embodiment of this application.

[0032] Figure 8 This is a flowchart of an interface compatibility conversion method provided in an embodiment of this application.

[0033] Figure 9 This is a flowchart of an interface compatibility conversion method provided in an embodiment of this application.

[0034] Figure 10 This is a block diagram of an electronic device provided in one embodiment of this application. Detailed Implementation

[0035] The specific embodiments of this application will be described in detail below with reference to the accompanying drawings. It should be understood that the specific embodiments described herein are for illustration and explanation only and are not intended to limit this application.

[0036] It should be understood that the term "comprising" and its variations as used herein are open-ended, meaning "including but not limited to". The term "based on" means "at least partially based on". The term "one embodiment" means "at least one embodiment"; the term "another embodiment" means "at least one additional embodiment"; the term "some embodiments" means "at least some embodiments". Definitions of other terms will be given in the following description.

[0037] It should be noted that the concepts of "first" and "second" mentioned in this application are only used to distinguish different devices, modules, or units, and are not used to limit the order of functions performed by these devices, modules, or units or their interdependencies. The modifications of "one" and "multiple" mentioned in this application are illustrative rather than restrictive, and those skilled in the art should understand that, unless explicitly stated in the context, they should be understood as "one or more". In the description of this application, unless otherwise stated, "multiple" means two or more, and other quantifiers are similar; "at least one item", "one item or multiple items", or similar expressions refer to any combination of these items, including any combination of single or multiple items.

[0038] Although operations or steps are described in a specific order in the accompanying drawings in the embodiments of this application, this should not be construed as requiring these operations or steps to be performed in the specific order or serial order shown, or requiring all of the shown operations or steps to be performed to obtain the desired result. In the embodiments of this application, these operations or steps may be performed serially; they may be performed in parallel; or a portion of these operations or steps may be performed.

[0039] The names of the messages or information exchanged between multiple devices in the embodiments of this application are for illustrative purposes only and are not intended to limit the scope of these messages or information. It is understood that before using the technical solutions disclosed in the embodiments of this application, users should be informed of the types, scope of use, and usage scenarios of the personal information involved in this application in an appropriate manner in accordance with relevant laws and regulations, and user authorization should be obtained. The application will now be described in conjunction with specific embodiments.

[0040] Figure 1 This is a flowchart illustrating an interface compatibility conversion method provided in an embodiment of this application. For example... Figure 1 As shown in the figure, this application provides an interface compatibility conversion method, which may include the following steps: In step S10, a field semantic constraint graph is constructed based on the collected target information. The target information includes the new version definition information, old version definition information, historical request responses, distributed call chains, and field access events at runtime of the target interface. The field access events at least record the complete hierarchical path of the field being read, the consumer identifier and corresponding version that initiated the read, and the type of operation performed on the field at runtime. The nodes of the field semantic constraint graph include the old field nodes, new field nodes, and consumer nodes of the target interface. The consumer node represents the consumer entity that actually reads the field at runtime and its corresponding version. The edges of the field semantic constraint graph include edges used to represent actual reading, version substitution, unit conversion, enumeration correspondence, derived calculation, or common constraint relationships between nodes.

[0041] In step S20, one or more candidate field mappings are generated based on the field semantic constraint graph. Each candidate field mapping includes a confidence score, the corresponding field path in the old version definition information and the new version definition information, and also includes one or more of the following: conversion action prompt, applicable version range, and evidence reference.

[0042] In step S30, candidate fields with confidence scores greater than a first preset threshold are mapped and compiled into deterministic compatibility rules. The deterministic compatibility rules consist of predefined action primitives of the target interface and are used to perform static security checks.

[0043] In step S40, based on historical traffic samples, the first shadow playback of the target interface based on the old interface path and the second shadow playback of the target interface based on the new interface path are executed according to the deterministic compatibility rule, so as to compare the semantic consistency of the target interface under the old interface path and the target interface under the new interface path, and determine whether to publish the deterministic compatibility rule based on the comparison result of the semantic consistency.

[0044] For example, target information can be collected at runtime. This target information may include new version definition information of the target interface, old version definition information, historical request responses, distributed call chains, and runtime field access events. Field access events should at least record the complete hierarchical path of the field being read, the consumer identifier and corresponding version that initiated the read, and the type of operation performed on the runtime field.

[0045] Based on this information, a field semantic constraint graph can be constructed. Nodes can include old field nodes, new field nodes, and consumer nodes. Consumer nodes represent the consumer entity that actually reads the field at runtime and its corresponding version. Edges can include actual reads, version substitutions, unit conversions, enumerated correspondences, derived calculations, or common constraint relationships.

[0046] Specifically, an edge can represent a business-meaning and verifiable relationship between nodes. An edge can be a directed edge, an undirected edge, or a superedge, and can carry one or more of the following attributes: edge type, starting node, ending node, applicable version range, evidence reference, confidence level, consumer version, and time window.

[0047] (1) Actual Read Edge. An actual read edge indicates that the consumer node actually reads an old or new field node during runtime. This edge points from the consumer node to the read field node and can record the consumer identifier, consumer version, complete field hierarchy path, operation type, read frequency, tracking identifier, de-identified usage summary, and timestamp. For example, in Android v5, the consumer node points to the old field node order.amount via an actual read edge. The edge attributes can indicate that the operation is read, null check, division by 100, and formatted as currency. This edge is used to prove that the field is actually consumed, rather than just existing in the interface definition.

[0048] (2) Version Substitution Edge. A version substitution edge represents the version evolution relationship between an old field node and a new field node, which can include renaming, hierarchical movement, type change, splitting, merging, null value semantic change, or default value change. This edge can point from an old field node to a new field node and can include the applicable version range. For example, the old field node order.amount points to the new field node order.totalAmount via a version substitution edge, indicating that amount in v3 is replaced by totalAmount in v4. If the old state value PAID is split into PAYMENT_CONFIRMED and SETTLED in the new version, there can be two version substitution edges, each with different conditions.

[0049] (3) Unit Conversion Edge. A unit conversion edge indicates that there is a relationship of measurement units or conversion scales between two field nodes. This edge can include a conversion factor, offset, rounding mode, precision, and time zone information. For example, the old field order.amount represents "cents" and the new field order.totalAmount represents "yuan". A unit conversion edge can be established between them with a conversion factor of 0.01 and a rounding mode of two decimal places. This edge can be used for static verification of unit dimension consistency and can be compiled into a unit conversion action primitive.

[0050] (4) Enumeration Correspondence Edge. An enumeration correspondence edge represents the correspondence between the enumeration values ​​of the old enumeration field and the enumeration values ​​of the new enumeration field. It can include one-to-one, one-to-many, many-to-one, conditional mapping, and default mapping. For example, the old enumeration value payStatus=PAID can be pointed to the new enumeration value payStatus=PAYMENT_CONFIRMED via an enumeration correspondence edge; when the settlement condition is met, the old enumeration value PAID can also be pointed to the new enumeration value SETTLED via another enumeration correspondence edge. This edge can be used for enumeration coverage integrity verification and can be compiled into an enumeration mapping action primitive.

[0051] (5) Derived Computed Edges. A derived computed edge represents a target field node obtained by calculating, concatenating, splitting, or conditionally selecting one or more source field nodes. This edge can point from a source field node to a target field node and can include computed expressions, action primitives, dependency conditions, and rounding rules. For example, the field nodes unitPrice, quantity, and discount can each point to the field node totalAmount via derived computed edges, with the edge attribute representing totalAmount = unitPrice × quantity - discount. This edge can be used for transformations such as field merging, field splitting, and conditional selection.

[0052] (6) Common Constraint Edges. Common constraint edges represent joint occurrence, mutual exclusion, conservation, order, or conditional dependency relationships between field nodes or between a field node and a business invariant node. This edge can be undirected or can connect multiple field nodes through a business invariant node. For example, an order constraint edge can be established between the startTime field node and the endTime field node, indicating that startTime≤endTime; a conservation constraint edge can be established between totalAmount, unitPrice, quantity, and discount, indicating that totalAmount=unitPrice×quantity-discount; a joint occurrence edge can be established between order.amount and order.currency, which can be used to compare whether cross-field invariants are maintained during shadow playback.

[0053] In addition, fallback dependency edges can be included to indicate a fallback from the target field to the old field, default value, or a degradation path when the transformation fails. For example, if the transformation of the new field totalAmount fails, a fallback dependency edge can point to the old field amount or the default value node.

[0054] Through the aforementioned edge types, directions, attributes, and examples, the field semantic constraint graph can clearly express relationships such as actual reading, version substitution, unit conversion, enumeration correspondence, derived calculation, and common constraints. It can also provide a clear basis for candidate field mapping generation, deterministic compatibility rule compilation, static security verification, and shadow playback.

[0055] Subsequently, a set of candidate field mappings is generated based on the field semantic constraint graph. Each candidate field mapping includes a confidence score, and may also include the corresponding field paths in the old version definition information and the new version definition information, as well as one or more of the following: conversion action prompts, applicable version range, and evidence citations.

[0056] Candidate fields with confidence scores greater than a first preset threshold can be mapped and compiled into deterministic compatibility rules. These rules consist of predefined action primitives for the target interface and are used to perform static security checks. Then, based on historical traffic samples, the first shadow replay of the target interface based on the old interface path and the second shadow replay of the target interface based on the new interface path are executed according to the deterministic compatibility rules. This compares the semantic consistency of the target interfaces under the old and new interface paths, and determines whether to publish the deterministic compatibility rule based on the semantic consistency comparison results.

[0057] In this embodiment, shadow replay refers to selecting and anonymizing target samples from historical traffic without affecting production operations, sending the same input sample to both the old and new interface execution paths, re-executing it in a shadow environment, and comparing whether the results of the two executions maintain consistency in business semantics. Here, "shadow" indicates that the replay process does not produce real external side effects; database writes, message sending, payment operations, notification sending, etc., can be intercepted by the shadow proxy or written to isolated storage; "replay" means using historical real request responses, rather than just using pre-written fixed test cases.

[0058] Specifically, the first shadow replay can be executed based on the old interface path, serving as the baseline for the old behavior; the second shadow replay can be executed based on the new interface path, and can load or apply deterministic compatibility rules as verification of the new behavior. Both replays can use the same anonymized sample. Comparison objects can include the final read value of the target field by the real consumer, the execution summary of the business branch, cross-field invariants, default values ​​and fallback paths when a field is missing, permission decisions, and state machine transitions. The comparison does not require the new and old complete messages to be identical word-for-word; instead, semantic consistency is judged based on unit normalization, allowed precision, and enumerated equivalence relations.

[0059] For example, when the order interface is upgraded from v3 to v4, the old field `order.amount` represents "cents," while the new field `order.totalAmount` represents "yuan." Shadow replay can route the same historical order through both the old and new interface paths. The old path retrieves `amount`, while the new path converts it to `totalAmount` using `unit_scale`. The displayed value (`amount` divided by 100) read from the old client is then compared to the `totalAmount` value read from the new path. Invariants such as amount conservation, `startTime≤endTime`, and `payStatus` status branches are checked. If the old version uses 0 for empty amounts while the new interface uses null, a `default_if_absent` rule with consumer version conditions can be added before replaying. Rule confidence is calculated based on replay pass rate, key consumer coverage, and risk invariant results, leading to decisions on rejection, manual approval, or phased rollout. When online semantic deviation reaches a threshold, the rule can be automatically revoked, and the system can switch back to the old interface or downgrade the path. Thus, shadow replay enables consumer-level semantic verification, reducing the risk of silent data errors.

[0060] The interface carrier can include REST, GraphQL, RPC, Protobuf, Avro, message queue payloads, database records, configuration objects, or combinations thereof. Rule execution locations can include server-side gateways, microservice adaptation layers, message transformation layers, database access layers, or client SDKs. Versioned interfaces are associated with asset identifiers (asset_id), call chain identifiers (trace_id), consumer identifiers (consumer_id), and rule versions (rule_version).

[0061] A typical process may include collecting interface definitions, historical traffic, call chains, and field access paths; constructing a field semantic constraint graph and locating real consumers; generating candidate mappings with evidence using artificial intelligence; compiling the candidates into restricted deterministic rules and performing static verification; performing shadow playback of old and new interfaces using historical traffic from the same source; verifying consumer reading results and cross-field invariants; calculating confidence levels and then conducting canary releases; and automatically rolling back based on online semantic deviations.

[0062] Therefore, the embodiments of this application combine real field access evidence, semantic constraint graph, candidate mapping, deterministic rule compilation, shadow playback and release decision into a processing chain, avoiding only comparing field names and declaration types, and can identify unit, enumeration, null value semantics and cross-field constraint changes, reducing the risk of silent data errors, thereby achieving secure release of interface deterministic compatible rules.

[0063] Optionally, the runtime field access event may also include a tracking identifier, interface endpoint, de-identified summary of the field's subsequent usage, and a timestamp. The operation type includes reading, null checking, comparison, arithmetic, concatenation, or branching judgment. The runtime field access event is obtained through bytecode instrumentation, compiler plugins, proxy objects, serialization hooks, gateway plugins, data access proxies, or a combination of static analysis and runtime sampling.

[0064] For example, field access events may also include tracking identifiers, interface endpoints, de-identified summaries of subsequent field usage, and timestamps. Operation types may include read, null check, comparison, arithmetic, concatenation, or branching. Field access events can be obtained through bytecode instrumentation, compiler plugins, proxy objects, serialization hooks, gateway plugins, data access proxies, or a combination of static analysis and runtime sampling.

[0065] In this way, the data collection agent can be deployed on API gateways, server-side frameworks, serialization components, database access layers, or client SDKs to record the actual reading events of consumers without recording the original sensitive values.

[0066] For example, runtime field access event A can be represented as: A=(trace_id, consumer_id, consumer_version, endpoint, field_path, operation, use_digest, timestamp) Formula 1 Where A represents a runtime field access event; trace_id represents the trace identifier associated with the access event and the same request or call chain; consumer_id represents the consumer identifier that initiated the field read; consumer_version represents the version of the consumer application, SDK, or component; endpoint represents the interface endpoint where the field access occurred; field_path represents the complete hierarchical path of the accessed field in the request or response object; operation represents the operation performed on the field, such as read, null check, comparison, arithmetic, concatenation, or branch judgment; use_digest represents a de-identified summary of how the field will be used subsequently; and timestamp represents the time when the access event occurred or the time window to which it belongs.

[0067] For example, an Android client can read order.amount, divide it by 100, and format it as currency. This field can be used for ratio conversion and display, without saving the user's actual amount.

[0068] This approach is also suitable for carriers such as REST, GraphQL, RPC, Protobuf, Avro, message queue payloads, database records, and configuration objects.

[0069] Therefore, the embodiments of this application can associate fields with the real consumer version, call chain and subsequent business functions, distinguish between fields that have never been read and key fields that participate in amount calculation, permission judgment or status transition, and provide operational evidence for risk ranking and candidate mapping.

[0070] Optionally, the semantic feature vector of each field node in the field semantic constraint graph may include: The target field declaration type and runtime observation type, the business measurement unit or conversion scale corresponding to the target field, the allowed range or historical observation value range of the target field, the enumeration value set and the business meaning of each enumeration value, whether the target field is allowed to be empty and the default value and empty judgment semantics when missing, the hierarchical path and structural context of the target field, the operation method performed by the real consumer on the target field, the frequency of joint occurrence of the target field with other fields and common constraint relationships, and various semantic descriptions in the interface definition or business document.

[0071] For example, the semantic feature vector of each field node in the field semantic constraint diagram may include the target field declaration type and runtime observation type, the business measurement unit or conversion scale corresponding to the target field, the allowed range or historical observation value range of the target field, the set of enumerated values ​​and the business meaning of each enumerated value, whether the target field is allowed to be empty and the default value and empty judgment semantics when missing, the hierarchical path and structural context of the target field, the operation method performed by the real consumer on the target field, the frequency of joint occurrence of the target field and other fields and the common constraint relationship, as well as multiple items in the semantic description in the interface definition or business document.

[0072] During construction, each field can be represented as a field node. Field nodes can further include interface or message identifiers, versions, field paths, declaration types, units, value ranges, enumeration sets, nullability, default semantics, sensitivity levels, and consumer sets. Equivalence, derivation, inclusion, mutual exclusion, conservation, order, and version substitution relationships can be established between fields. Semantic constraint graphs can be implemented using attribute graphs, knowledge graphs, relational tables, vector indexes, or combinations of these data structures.

[0073] For example, a field semantic constraint graph can be represented as G=(V,E), where node V can include old field nodes, new field nodes, consumer nodes, transformation action nodes, and business invariant nodes; edge E can represent actual reads, version replacements, unit conversions, enumeration correspondences, derived calculations, common constraints, or fallback dependencies.

[0074] The field semantic vector X(f) can be represented as: X(f) = [type, unit, range, enum, nullability, path_context, consumer_use, co_occurrence, documentation] (Formula 2) Where f represents the old or new field to be described, X(f) represents the multidimensional semantic feature vector of field f; type represents the field declaration type and runtime observation type; unit represents the business unit of measurement or conversion scale corresponding to the field; range represents the allowed range of the field or the range of historical observation values; enum represents the set of enumerated values ​​and the business meaning of each enumerated value; nullability represents whether the field is allowed to be empty, the default value when missing, and the semantics for null judgment; path_context represents the hierarchical path of the field and the structural context formed by the parent node, child node, and adjacent fields; consumer_use represents the reading, comparison, conversion, splicing, display, or branch judgment method performed by the real consumer on the field, which comes from the real field access event; co_occurrence represents the frequency of joint occurrence of this field with other fields and the common constraint relationship; documentation represents the semantic description of this field in the interface definition, field comments, or business documentation.

[0075] As an example, the old field `amount` is declared as an integer, with an observation range of 0 to 50,000,000, and is read by the client, divided by 100, and displayed in currency format; the new field `totalAmount` is declared as a decimal, with the unit specified as yuan. Even if the names are not very similar, the unit dimension, consumer usage, and historical value distribution can still support the candidate relationship of "amount (cents) → totalAmount (yuan)".

[0076] Therefore, even though the old field `amount` represents cents and the new field `totalAmount` represents yuan, and the names are not highly similar, the unit dimension, consumer usage patterns, and historical value distribution can still support candidate relationships in this embodiment. This semantic feature vector can also identify cases where the names are the same but the units or enumeration meanings have changed, providing fine-grained basis for subsequent change detection, risk classification, and candidate mapping.

[0077] Figure 2 This is a flowchart illustrating an interface compatibility conversion method provided in an embodiment of this application. For example... Figure 2 As shown, generating one or more candidate field mappings based on the field semantic constraint graph may include the following steps: In step S201, the new interface definition and the old interface definition are structurally aligned to generate a field change set. The consumers affected by the changes and their corresponding risk levels in the field change set are located according to the field semantic constraint graph. The change types of the field change set include multiple types such as addition, deletion, renaming, hierarchical movement, type change, unit change, enumeration recoding, splitting, merging, null value semantic change, and default value change. The risk level is obtained based on multiple factors such as consumer importance, reading frequency, operation sensitivity, semantic change magnitude, and historical anomaly rate.

[0078] In step S202, the field semantic subgraph, pattern difference, field document summary, value distribution summary, and consumer usage summary corresponding to the consumers affected by the change are input into the artificial intelligence model so that the artificial intelligence model outputs one or more candidate field mappings.

[0079] For example, generating a set of candidate field mappings based on a field semantic constraint graph may include the following process.

[0080] The system can perform structural alignment between new and old interface definitions to generate a set of field changes. Based on the field semantic constraint graph, it can locate the consumers affected by the changes and their corresponding risk levels within the set. The change types in the field change set can include multiple categories such as addition, deletion, renaming, hierarchical movement, type change, unit change, enumeration recoding, splitting, merging, null value semantic changes, and default value changes. Risk levels can be obtained based on multiple categories such as consumer importance, read frequency, operational sensitivity, semantic change magnitude, and historical anomaly rate.

[0081] The semantic subgraphs of fields, pattern differences, field document summaries, value distribution summaries, and consumer usage summaries corresponding to consumers affected by the changes can be input into the AI ​​model, causing the AI ​​model to output a set of candidate field maps. Candidate field maps can include source_path, target_path, transform_hint, applicable_versions, evidence_refs, and confidence, and can also include one or more of the following: transformation action hints, applicable version ranges, and evidence citations.

[0082] Candidate mapping models can employ large language models, graph neural networks, retrieval enhancement models, gradient boosting trees, rule systems, or combinations thereof. They can also collect new and old interface definitions, Protobuf descriptions, database schemas, version information, historical request and response data, and distributed call chains. For Protobuf messages, they can also collect field numbers, oneof relationships, optional semantics, default values, unknown field retention behavior, and actual read paths. Field number reuse, numeric type narrowing, or oneof branch changes can be marked as high-risk. When the old field `price_cent` is `int64` and the new field `price` is `Money`, the candidate rule can use the `compose_fields` action to convert `price_cent` to `Money.amount` and supplement the `currency` field.

[0083] Shadow replay simultaneously verifies whether the old consumer can ignore unknown fields, whether the new consumer receives the same amount after reading Money, and whether serialization and deserialization round trips remain unchanged. For database field upgrades, it can obtain table structure, data access object fields, query projection, change data capture events, and interface serialization paths. Semantic graphs connect database columns, domain object fields, interface fields, and client consumption fields to form cross-layer field access paths. During field splitting or unit migration, compatibility rules can simultaneously support dual reads, controlled dual writes, and validation reads. Shadow tasks compare the calculation results of the old columns with the combined results of the new columns, but do not write the shadow results to the production master table. Switching the primary read path is only allowed when the consistency rate reaches a threshold and covers the entire business cycle. Old column reads are restored when deviations occur.

[0084] Therefore, the embodiments of this application can combine static schema differences with real consumer evidence to distinguish unused fields, display fields, calculated fields, and key fields controlling business branches, narrowing the candidate mapping space and allowing the model to output suggestions with evidence and confidence, rather than directly modifying or executing interface code.

[0085] Figure 3 This is a flowchart illustrating an interface compatibility conversion method provided in an embodiment of this application. For example... Figure 3 As shown, before mapping and compiling candidate fields with confidence scores greater than a first preset threshold into deterministic compatibility rules, the method may further include the following steps: In step S25, if the difference between the confidence scores of the candidate field mapping with the highest confidence score and the candidate field mapping with the second highest confidence score is lower than the difference threshold, then the deterministic compatibility rule is manually confirmed without proceeding to the compilation step. The confidence score of the candidate field mapping is obtained from multiple factors including semantic similarity, consumer usage similarity, statistical distribution matching degree, business constraint satisfaction degree, historical support degree, privacy risk, and ambiguity.

[0086] In step S26, if the candidate field mapping lacks unit and enumeration evidence, the deterministic compatibility rule is manually verified without proceeding to the compilation step.

[0087] For example, manual confirmation of access control can also be performed before candidate fields with confidence scores greater than a first preset threshold are mapped and compiled into deterministic compatibility rules.

[0088] If the difference in confidence scores between the candidate field mapping with the highest confidence score and the candidate field mapping with the second highest confidence score is less than the difference threshold, then the deterministic compatibility rule is manually verified and the process does not proceed to the compilation step. The confidence score of the candidate field mapping can be obtained based on multiple factors including semantic similarity, consumer usage similarity, statistical distribution matching, business constraint satisfaction, historical support, privacy risk, and ambiguity. If the candidate field mapping lacks unit and enumeration evidence, then the deterministic compatibility rule is manually verified and the process does not proceed to the compilation step.

[0089] For example, the confidence score M(o,n) can be represented as: M(o,n)=α1×semantic_similarity+α2×consumer_use_similarity+α3×distribution_fit+α4×constraint_fit+α5×history_support α6×privacy_risk α7×ambiguity formula 3 Wherein, o represents the source field in the old interface, n represents the candidate target field in the new interface, M(o,n) represents the confidence score of mapping field o to field n, and the higher the score, the greater the possibility of a compatible mapping; α1 to α7 represent the non-negative weights of each evaluation item, which can be calibrated based on historical verification results, business risks, or training data; semantic_similarity represents the semantic similarity of field names, document descriptions, and entity relationships; consumer_use_similarity represents the similarity of the old and new fields in terms of consumer-side reading, calculation, display, and branch judgment methods; distribution_fit represents the degree of matching of field types, value ranges, and statistical distributions after candidate transformation; constraint_fit represents the degree of satisfaction of type, unit, enumeration, nullability, cross-field constraints, and business invariants; history_support represents the degree of support for the candidate relationship from historical version mapping, manual confirmation records, and shadow playback results; privacy_risk represents the risk that the transformation will cause exposure of sensitive information, expansion of the scope of permissions, or change of data usage; ambiguity represents the uncertainty caused by multiple candidate scores being close, conflicting evidence, or insufficient evidence.

[0090] Therefore, the embodiments of this application can avoid the model automatically generating rules when candidate scores are close, evidence conflicts, or evidence is insufficient, reducing the risk of sensitive information exposure, expansion of the scope of permissions, or change in data usage. In cases where semantic equivalence cannot be proven, only diagnostic reports and manual migration suggestions can be generated, without generating publishable rules.

[0091] Optionally, the deterministic compatibility rule may include multiple elements such as scope of application, source path, target path, preconditions, conversion actions, invariant constraints, fallback actions, validity period, and evidence hash; the scope of application is limited to the interface, service version, consumer version, and traffic bucket; the preconditions are limited to the existence, type, and value range of the field; the predefined action primitives include multiple elements such as path selection, type conversion, unit conversion, enumeration mapping, default value filling, field splitting, field merging, fallback actions, rounding mode, time zone conversion, and condition selection.

[0092] For example, deterministic compatibility rules can include multiple parameters such as scope, source path, target path, preconditions, transformation actions, invariant constraints, fallback actions, validity period, and evidence hashes. Scope limits the interface, service version, consumer version, and traffic bucket. Preconditions limit the existence, type, and value range of fields. Predefined action primitives can include multiple parameters such as path selection, type conversion, unit conversion, enumeration mapping, default value filling, field splitting, field merging, fallback actions, rounding modes, time zone conversion, and condition selection. The rule compiler prohibits arbitrary network access, file access, loops, reflection, and unregistered function calls, thereby ensuring that the same input produces the same output.

[0093] Candidate suggestions that pass the confidence threshold are compiled into restricted, auditable deterministic rules. The static validation module verifies whether the source and target paths exist, whether type conversions are closed, whether unit dimensions match, whether enumerations are overridden, whether values ​​are out of bounds, whether default values ​​satisfy null semantics, whether rules conflict, and whether circular dependencies exist. Deterministic rules can be executed at the server-side gateway, microservice adaptation layer, message conversion layer, database access layer, or client SDK.

[0094] For example, the deterministic compatibility rule R can be expressed as: R=(scope, source_path, target_path, precondition, transform,invariant, fallback, ttl, evidence_hash) Formula 4 Among them, scope limits the interface, service version, consumer version, and traffic bucket; precondition limits the existence, type, and value range of the field; transform can only be composed of predefined action primitives; invariant is the constraint that must be maintained; fallback is the old field or fallback path when the definition fails; ttl is the validity period; evidence_hash is the evidence used when generating association rules.

[0095] Therefore, the embodiments of this application restrict the model suggestions to predefined action boundaries, making interface compatibility conversion deterministic, auditable and rollbackable, and avoiding silent errors introduced by freely generated code.

[0096] Figure 4 This is a flowchart illustrating an interface compatibility conversion method provided in an embodiment of this application. For example... Figure 4As shown, before performing the first shadow replay of the target interface based on the old interface path and the second shadow replay of the target interface based on the new interface path according to the deterministic compatibility rules based on historical traffic samples, in order to compare the semantic consistency of the target interface under the old interface path and the target interface under the new interface path, the method may further include the following steps: In step S35, if any verification in the static security check fails, the deterministic compatibility rule is prevented from entering shadow playback. The static security check includes multiple checks such as type closure, unit dimension consistency, enumeration value coverage integrity, value boundary security, rule circular dependency, rule conflict, and prohibited access fields.

[0097] For example, a static security check access control can also be set before performing the first shadow playback and the second shadow playback based on historical traffic samples.

[0098] In the event of any failure in static security validation, deterministic compatible rules are prevented from entering shadow replay. Static security validation can include verifying type closure, unit dimension consistency, enumeration value coverage integrity, value boundary security, rule circular dependencies, inter-rule conflicts, and multiple items from prohibited access fields. Any validation failure prevents the rule from entering replay. This access control can also be combined with rule audit logs to write validation results into the sample database for updating the candidate ranking model and risk model.

[0099] Therefore, the embodiments of this application can eliminate problems such as non-closed type, inconsistent unit dimension, incomplete enumeration coverage, out-of-bounds value, circular dependency of rules, rule conflict and prohibited field access before traffic verification, thereby reducing the risk of subsequent shadow playback and online release.

[0100] Figure 5 This is a flowchart illustrating an interface compatibility conversion method provided in an embodiment of this application. For example... Figure 5 As shown, the step of performing a first shadow replay of the target interface based on the old interface path and a second shadow replay of the target interface based on the new interface path according to the deterministic compatibility rule based on historical traffic samples, to compare the semantic consistency of the target interface under the old interface path and the target interface under the new interface path, and determining whether to publish the deterministic compatibility rule based on the comparison result of the semantic consistency, may include the following steps: In step S401, target samples covering the affected consumers, versions, enumeration values, boundary values, and field combinations are selected from historical traffic. After desensitizing the target samples, the first shadow playback of the target interface based on the old interface path and the second shadow playback of the target interface based on the new interface path are executed on the same desensitized sample, and external side effects are isolated.

[0101] In step S402, the final read value of the target field by the real consumer, the business branch execution summary, and cross-field invariants are compared under the old interface path and the new interface path to determine semantic consistency, and the rule confidence is calculated based on the verification pass rate.

[0102] In step S403, the deterministic compatibility rule is determined to be rejected, manually approved, or published in a grayscale ratio based on the rule confidence level, and the published deterministic compatibility rule is revoked when the online semantic deviation index reaches the second preset threshold.

[0103] For example, performing a first shadow playback and a second shadow playback based on historical traffic samples, and determining whether to publish accordingly, may include the following process.

[0104] Target samples covering affected consumers, versions, enumerated values, boundary values, and field combinations can be selected from historical traffic. After anonymizing the target samples, a first shadow replay of the target interface based on the old interface path and a second shadow replay of the target interface based on the new interface path are executed using the same anonymized samples, while isolating external side effects. The final read values ​​of the target fields by real consumers, business branch execution summaries, and cross-field invariants are compared under the old and new interface paths to determine semantic consistency, and the rule confidence is calculated based on the validation pass rate. Based on the rule confidence, a deterministic compatibility rule is determined to be rejected, manually approved, or released in a gray-scale manner. The released deterministic compatibility rule is revoked when the online semantic deviation index reaches a second preset threshold.

[0105] Shadow playback does not require the old and new complete messages to be identical word for word; instead, it replays the consumer's reading based on the actual access path. Sample validation loss can consider value differences, invariant violations, branch differences, and backoff differences. For high-risk consumers, the loss can be required to be zero; for scenarios such as floating-point displays, an allowable precision can be set.

[0106] For example, the sample validation loss L(s) can be expressed as: L(s)=μ1×value_diff+μ2×invariant_violation+μ3×branch_diff+μ4×fallback_diff Formula 5 Wherein, s represents a historical request-response sample that has been anonymized and entered into the shadow environment; L(s) represents the comprehensive verification loss of the candidate conversion rule on sample s, with a smaller value indicating more consistent execution results between the old and new versions; μ1 to μ4 represent the non-negative weights of each loss item, which can be configured according to the consumer's risk level and business tolerance; value_diff represents the normalized value of the difference in field values, types, units, or precision before and after conversion; invariant_violation represents the indication or penalty value generated when business invariants such as amount conservation, time sequence, and state legality are violated; branch_diff represents the difference in control flow branches, condition judgment results, or abnormal branches during the execution of the old and new consumers; and fallback_diff represents the difference in whether the old and new executions enter different default values, fallback paths, or degradation paths when fields are missing or conversion fails.

[0107] In the example, if the order interface is upgraded from v3 to v4, `order.amount` is migrated from an integer fraction to `order.totalAmount` in decimal form, and the `payStatus` enumeration value is adjusted. Evidence shows that `amount` is read by 86% of older clients, with 72% of read paths containing currency formatting after division by 100. `payStatus` participates in all three order status branches. The semantic graph generates three candidate mappings for the amount. Artificial intelligence prioritizes `amount ÷ 100` to `totalAmount`, with a candidate confidence of 0.93, and cites evidence of units, value distribution, and consumer usage.

[0108] The rule compiler generates `unit_scale(0.01)` and rounding rules to two decimal places, and also generates an explicit `enum_map` for `payStatus`. Static validation confirms complete coverage of the unit dimension and enumeration. 28,000 shadow samples can be selected, covering empty orders, refunds, discounts, maximum amounts, various client versions, and all status enumerations. All high-risk invariants pass, and the consistency rate after amount standardization is 99.998%. The remaining 0.002% deviation comes from the old version using 0 for empty amounts and the new interface using null. After adding a `default_if_absent` rule with consumer version conditions and replaying, the consistency rate reaches 100%.

[0109] The rule can be initially enabled for 1% of matching traffic, and if there are no parsing anomalies or invariant failures within 24 hours, it can be expanded to 20%. If the amount deviation or the error rate of the old client reaches the threshold, the platform will automatically revoke the rule and restore the v3 path.

[0110] Therefore, this application embodiment advances the verification from the message layer to the consumer read value and business invariant layer, thereby enabling the discovery of silent errors with similar JSON structures but inconsistent amount, time, status judgment or degradation behavior.

[0111] Optionally, the desensitization process may employ one or more of the following methods: typed placeholders, order-preserving tokens, intervalization, or structured summarization; the external side effects include database writing, message sending, payment operations, and notification sending, which may be intercepted by the shadow agent or written to isolated storage; the target sample selection may employ one or more of the following methods: coverage optimization, stratified sampling, boundary value generation, cluster center selection, or risk-based active sampling.

[0112] For example, anonymization can employ one or more of the following methods: typed placeholders, order-preserving tokens, interval mapping, or structured summaries. External side effects can include database writes, message sending, payment operations, and notification sending, which can be intercepted or written to isolated storage by a shadow agent. Target sample selection can be achieved using one or more of the following methods: coverage optimization, stratified sampling, boundary value generation, cluster center selection, or risk-based active sampling. Privacy protection can also employ anonymization, tokenization, interval mapping, differential privacy, trusted execution environments, or uploading only statistical summaries.

[0113] Therefore, the embodiments of this application can reduce the risk of sensitive information exposure while maintaining cross-field relationships and business verifiability, and allow shadow playback to cover long-tail field combinations, old client versions, canary configurations, and cross-service call paths.

[0114] Figure 6 This is a flowchart illustrating an interface compatibility conversion method provided in an embodiment of this application. For example... Figure 6 As shown, determining semantic consistency may include the following steps: In step S4021, the target value read by the real consumer is compared with the old value after semantic normalization.

[0115] In step S4022, the consistency of cross-field invariant preservation, default values ​​triggered when a field is missing, and fallback paths is compared.

[0116] In step S4023, the true or false results of the key condition judgment, the permission decision, and the state machine transition are compared to see if they are consistent.

[0117] For example, determining semantic consistency may include the following comparisons: comparing whether the target value read by the actual consumer is consistent with the old value after semantic normalization; if consistent, then comparing whether the cross-field invariant retention, the default value triggered when a field is missing, and the fallback path are consistent; if still consistent, then comparing whether the true / false results of key condition judgments, permission decisions, and state machine transitions are consistent; if all the above comparisons are consistent, then semantic consistency is determined. If any comparison is inconsistent, then semantic inconsistency is determined, and the difference can be recorded or the verification loss can be calculated.

[0118] As another implementation, steps S4021, S4022 and S4023 can be executed without premature termination due to inconsistency of a single item. Finally, based on the summary of all comparison results, semantic consistency is determined when all are consistent; semantic inconsistency is determined when any item is inconsistent, and the verification loss is calculated according to the weights of each item.

[0119] Therefore, the embodiments of this application can verify the conservation of amount, the order of time, the legality of the status, the handling of default values ​​and the degradation path, rather than just comparing the complete message or JSON structure, thereby reducing the risk of the client displaying incorrect amount, time offset, incorrect status judgment or triggering incorrect business branches.

[0120] Figure 7 This is a flowchart illustrating an interface compatibility conversion method provided in an embodiment of this application. For example... Figure 7 As shown, the step of deciding whether to reject, manually approve, or release the deterministic compatibility rule according to the rule confidence level may include the following steps: In step S4031, automatic publishing is rejected when the rule confidence level is lower than the first threshold.

[0121] In step S4032, manual approval is initiated when the rule confidence level is between the first threshold and the second threshold.

[0122] In step S4033, grayscale release is allowed when the rule confidence is higher than the second threshold and all high-risk invariants pass, wherein the first threshold is less than the second threshold, and the rule confidence is obtained from multiple factors including evidence strength, historical sample coverage, replay consistency, key consumer coverage, rule complexity, and ambiguity.

[0123] For example, deciding whether to reject, manually review, or release in a phased rollout based on rule confidence levels may include the following process: Reject automatic release when rule confidence levels are below a first threshold. Proceed to manual review when rule confidence levels are between the first and second thresholds. Allow phased rollout when rule confidence levels are above the second threshold and all high-risk invariants pass. The first threshold is less than the second threshold. Rule confidence levels can be obtained based on multiple factors including evidence strength, historical sample coverage, replay consistency, key consumer coverage, rule complexity, and ambiguity.

[0124] For example, the rule confidence Q can be expressed as: Q=β1×evidence+β2×coverage+β3×replay_pass+β4×consumer_coverage β5×complexity β6×ambiguity formula 6 Where evidence is the strength of evidence, coverage is the historical sample coverage rate, replay_pass is the replay consistency rate, consumer_coverage is the key consumer coverage rate, complexity is the rule complexity, ambiguity is the rule ambiguity, and β1~β6 are the preset weights of each item.

[0125] Therefore, the embodiments of this application can process rules in layers according to their confidence level, blocking low-confidence rules from automatic release, handing over medium-confidence rules to manual review, and sending high-confidence rules with high-risk invariants to a small-scale gray release, thereby balancing upgrade efficiency and silent semantic error control.

[0126] Figure 8 This is a flowchart illustrating an interface compatibility conversion method provided in an embodiment of this application. For example... Figure 8 As shown, the grayscale release may include the following steps: In step S40331, the deterministic compatibility rule is bound to the applicable interface, service version, consumer version, traffic ratio, validity period and rollback indicator and digitally signed.

[0127] In step S40332, only deterministic compatibility rules with valid signatures and matching scope are loaded in the compatibility execution layer.

[0128] In step S40333, the deterministic compatibility rule is enabled and monitored in stages according to the matching traffic of the first percentage, the second percentage, the third percentage and the fourth percentage. The monitoring indicators include multiple ones such as rule hit rate, conversion failure rate, field missing rate, consumer parsing anomaly, cross-field invariant failure, key business success rate and old version client error rate. Among them, the first percentage is less than the second percentage, the second percentage is less than the third percentage and the third percentage is less than the fourth percentage.

[0129] For example, a canary rollout may include the following process: Deterministic compatibility rules are bound to applicable interfaces, service versions, consumer versions, traffic percentages, validity periods, and rollback metrics, and digitally signed. Only deterministic compatibility rules with valid signatures and matching scopes are loaded at the compatibility execution layer. The deterministic compatibility rules are enabled and monitored tiered according to matching traffic percentages of a first percentage, a second percentage, a third percentage, and a fourth percentage. Wherein, the first percentage is less than the second percentage, the second percentage is less than the third percentage, and the third percentage is less than the fourth percentage.

[0130] Monitoring metrics can include multiple metrics such as rule hit rate, conversion failure rate, field missing rate, consumer parsing anomalies, cross-field invariant failures, key business success rate, and old version client error rate. When a rule execution fails, a rollback action should be prioritized, and unvalidated intermediate values ​​should not be output. If any semantic deviation metric exceeds a threshold, the rule should be automatically revoked, and the system should switch back to the old interface or a preset fallback path.

[0131] When multiple services generate field conversion rules, the platform calculates the combined conversion along the call chain, checking for duplicate unit conversions, duplicate enumeration mappings, default value overriding, and path loops. If two rules write to the same target field and their preconditions overlap, the rule is selected based on version priority, evidence strength, and explicit conflict strategy. Unresolved conflicts proceed to manual approval.

[0132] Therefore, the embodiments of this application can realize rule signing, version matching, gray-scale binning, indicator monitoring and automatic rollback, avoid the accumulation of conflicting rules in the fixed compatibility layer, and allow multiple versions of the server, Android, iOS, Web and third-party callers to upgrade at their own pace.

[0133] Figure 9 This is a flowchart illustrating an interface compatibility conversion method provided in an embodiment of this application. For example... Figure 9 As shown, the method may further include the following steps: In step S50, the manually confirmed field relationships, static verification results, reasons for replay success or failure, online grayscale indicators, and rollback reasons are written into the sample library.

[0134] In step S60, the candidate ranking model is updated with the final confirmation mapping as the label, and the risk model is updated with the semantic bias and rollback results as the label.

[0135] In step S70, the new model is verified on the interface upgrade record that is later in time before it goes online, without reducing the recall rate of high-risk changes.

[0136] For example, embodiments of this application can also form a closed-loop learning mechanism. Manually confirmed field relationships, static validation results, reasons for successful or failed replays, online grayscale metrics, and rollback reasons can be written into a sample library. The candidate ranking model is updated with the final confirmation mapping as labels, and the risk model is updated with semantic bias and rollback results as labels. Before the new model goes live, it is validated on later interface upgrade records without reducing the recall rate of high-risk changes.

[0137] The candidate ranking model and semantic constraints can be updated with manually confirmed results, replay results, online hit results, and rollback reasons. When semantic equivalence cannot be proven, only diagnostic reports and manual migration suggestions can be generated, without generating publishable rules.

[0138] Therefore, the embodiments of this application can form an auditable technical closed loop of rule generation, verification, release and rollback, continuously improve the candidate ranking and risk identification capabilities, and at the same time maintain the recall rate of high-risk changes.

[0139] Figure 10 This is a block diagram of an electronic device provided in one embodiment of this application. For example... Figure 10 As shown, the electronic device 1000 may include: a processor 1001 and a memory 1002. The electronic device 1000 may also include one or more of a multimedia component 1003, an input / output (I / O) interface 1004, and a communication component 1005.

[0140] The processor 1001 controls the overall operation of the electronic device 1000 to complete all or part of the steps in the interface compatibility conversion method described above. The memory 1002 stores various types of data to support the operation of the electronic device 1000. This data may include, for example, instructions for any application or method operating on the electronic device 1000, and application-related data such as contact data, sent and received messages, pictures, audio, video, etc. The memory 1002 can be implemented by any type of volatile or non-volatile storage device or a combination thereof, such as Static Random Access Memory (SRAM), Electrically Erasable Programmable Read-Only Memory (EEPROM), Erasable Programmable Read-Only Memory (EPROM), Programmable Read-Only Memory (PROM), Read-Only Memory (ROM), magnetic storage, flash memory, magnetic disk, or optical disk. Multimedia component 1003 may include a screen and an audio component. The screen may be, for example, a touchscreen, and the audio component is used to output and / or input audio signals. For example, the audio component may include a microphone for receiving external audio signals. The received audio signals may be further stored in memory 1002 or transmitted via communication component 1005. The audio component also includes at least one speaker for outputting audio signals. I / O interface 1004 provides an interface between processor 1001 and other interface modules, such as a keyboard, mouse, buttons, etc. These buttons may be virtual or physical buttons. Communication component 1005 is used for wired or wireless communication between the electronic device 1000 and other devices. Wireless communication, such as Wi-Fi, Bluetooth, Near Field Communication (NFC), 2G, 3G, 4G, NB-IoT, eMTC, or other 5G technologies, or combinations thereof, is not limited here. Therefore, the corresponding communication component 1005 may include: a Wi-Fi module, a Bluetooth module, an NFC module, etc.

[0141] In an exemplary embodiment, the electronic device 1000 may be implemented by one or more application-specific integrated circuits (ASICs), digital signal processors (DSPs), digital signal processing devices (DSPDs), programmable logic devices (PLDs), field-programmable gate arrays (FPGAs), controllers, microcontrollers, microprocessors, or other electronic components to perform the interface compatibility conversion method described above.

[0142] In another exemplary embodiment, a computer-readable storage medium including program instructions is also provided, which, when executed by a processor, implement the steps of the interface compatibility conversion method described above. For example, the computer-readable storage medium may be the memory 1002 including the program instructions described above, which may be executed by the processor 1001 of the electronic device 1000 to complete the interface compatibility conversion method described above.

[0143] In another exemplary embodiment, a computer program product is also provided, comprising a computer program executable by a programmable device, the computer program having a code portion for performing the interface compatibility conversion method described above when executed by the programmable device.

[0144] The preferred embodiments of this application have been described in detail above with reference to the accompanying drawings. However, this application is not limited to the specific details of the above embodiments. Within the scope of the technical concept of this application, various simple modifications can be made to the technical solution of this application, and these simple modifications all fall within the protection scope of this application.

[0145] It should also be noted that the various specific technical features described in the above embodiments can be combined in any suitable manner without contradiction. In order to avoid unnecessary repetition, this application will not describe the various possible combinations separately.

[0146] Furthermore, various different implementations of this application can be combined in any way, as long as they do not violate the spirit of this application, they should also be regarded as the content disclosed in this application.

Claims

1. An interface compatibility conversion method, characterized in that, The method includes: A field semantic constraint graph is constructed based on the collected target information. The target information includes the new version definition information, old version definition information, historical request and response, distributed call chain, and field access events at runtime of the target interface. The field access events record at least the complete hierarchical path of the field being read, the consumer identifier and corresponding version that initiated the read, and the type of operation performed on the field at runtime. The nodes of the field semantic constraint graph include the old field nodes, new field nodes, and consumer nodes of the target interface. The consumer node represents the consumer entity that actually reads the field at runtime and its corresponding version. The edges of the field semantic constraint graph include edges used to represent actual reading, version substitution, unit conversion, enumeration correspondence, derived calculation, or common constraint relationships between nodes. One or more candidate field mappings are generated based on the field semantic constraint graph. Each candidate field mapping includes a confidence score, the corresponding field path in the old version definition information and the new version definition information, and also includes one or more of the following: conversion action prompt, applicable version range, and evidence reference. Candidate fields with confidence scores greater than a first preset threshold are mapped and compiled into deterministic compatibility rules. The deterministic compatibility rules consist of predefined action primitives of the target interface and are used to perform static security checks. Based on historical traffic samples, the first shadow playback of the target interface based on the old interface path and the second shadow playback of the target interface based on the new interface path are executed according to the deterministic compatibility rule, respectively, to compare the semantic consistency of the target interface under the old interface path and the target interface under the new interface path, and to determine whether to publish the deterministic compatibility rule based on the comparison result of the semantic consistency.

2. The method according to claim 1, characterized in that, The runtime field access events also include tracking identifiers, interface endpoints, de-identified summaries of subsequent field usage, and timestamps. The operation types include reading, null checking, comparison, arithmetic, concatenation, or branching. The runtime field access events are obtained through bytecode instrumentation, compiler plugins, proxy objects, serialization hooks, gateway plugins, data access proxies, or a combination of static analysis and runtime sampling.

3. The method according to claim 1, characterized in that, The semantic feature vector of each field node in the field semantic constraint graph includes: The target field declaration type and runtime observation type, the business measurement unit or conversion scale corresponding to the target field, the allowed range or historical observation value range of the target field, the enumeration value set and the business meaning of each enumeration value, whether the target field is allowed to be empty and the default value and empty judgment semantics when missing, the hierarchical path and structural context of the target field, the operation method performed by the real consumer on the target field, the frequency of joint occurrence of the target field with other fields and common constraint relationships, and various semantic descriptions in the interface definition or business document.

4. The method according to claim 1, characterized in that, The step of generating one or more candidate field mappings based on the field semantic constraint graph includes: The new and old interface definitions are structurally aligned to generate a set of field changes. The consumers affected by the changes and their corresponding risk levels are located in the set of field changes based on the field semantic constraint graph. The change types of the set of field changes include multiple types such as addition, deletion, renaming, hierarchical movement, type change, unit change, enumeration recoding, splitting, merging, null value semantic change, and default value change. The risk level is obtained based on multiple factors such as consumer importance, read frequency, operation sensitivity, semantic change magnitude, and historical anomaly rate. The field semantic subgraph, pattern difference, field document summary, value distribution summary, and consumer usage summary corresponding to the affected consumers are input into the artificial intelligence model so that the artificial intelligence model outputs one or more candidate field mappings.

5. The method according to claim 1, characterized in that, Before mapping and compiling candidate fields with confidence scores greater than a first preset threshold into deterministic compatibility rules, the method further includes: If the difference between the confidence scores of the candidate field mapping with the highest confidence score and the candidate field mapping with the second highest confidence score is lower than the difference threshold, then the deterministic compatibility rule is manually confirmed without proceeding to the compilation step. The confidence score of the candidate field mapping is obtained from multiple factors including semantic similarity, consumer usage similarity, statistical distribution matching degree, business constraint satisfaction degree, historical support degree, privacy risk, and ambiguity. If the candidate field mapping lacks unit and enumeration evidence, then the deterministic compatibility rule is manually verified without proceeding to the compilation step.

6. The method according to claim 1, characterized in that, The deterministic compatibility rules include multiple categories such as scope of application, source path, target path, preconditions, conversion actions, invariant constraints, fallback actions, validity period, and evidence hash; the scope of application is limited to interfaces, service versions, consumer versions, and traffic buckets; the preconditions are limited to the existence, type, and value range of fields; the predefined action primitives include multiple categories such as path selection, type conversion, unit conversion, enumeration mapping, default value filling, field splitting, field merging, fallback actions, rounding modes, time zone conversion, and condition selection.

7. The method according to claim 1, characterized in that, Before performing a first shadow replay of the target interface based on the old interface path and a second shadow replay of the target interface based on the new interface path according to the deterministic compatibility rules based on historical traffic samples, to compare the semantic consistency of the target interface under the old interface path and the target interface under the new interface path, the method further includes: In the event of any failure in the static security checks, the deterministic compatibility rule is prevented from entering shadow playback. The static security checks include multiple checks such as type closure, unit dimension consistency, enumeration value coverage integrity, value boundary security, rule circular dependency, rule conflict, and prohibited access fields.

8. The method according to claim 1, characterized in that, The step of performing a first shadow replay of the target interface based on the old interface path and a second shadow replay of the target interface based on the new interface path, according to the deterministic compatibility rule based on historical traffic samples, to compare the semantic consistency of the target interface under the old interface path and the target interface under the new interface path, and determining whether to publish the deterministic compatibility rule based on the comparison result of the semantic consistency, includes: Select target samples from historical traffic that cover the affected consumers, versions, enumeration values, boundary values, and field combinations. After de-identifying the target samples, perform a first shadow playback of the target interface based on the old interface path and a second shadow playback of the target interface based on the new interface path using the same de-identified sample, and isolate external side effects. Compare the final read value of the target field by the real consumer, the business branch execution summary, and cross-field invariants under the old interface path and the new interface path to determine semantic consistency, and calculate the rule confidence based on the validation pass rate; The deterministic compatibility rule is determined based on the confidence level of the rule, and is either rejected, manually approved, or published in a gray-scale ratio. The published deterministic compatibility rule is revoked when the online semantic deviation index reaches the second preset threshold.

9. The method according to claim 8, characterized in that, The desensitization process employs one or more of the following methods: typed placeholders, order-preserving tokens, interval processing, or structured summarization. The external side effects include database writing, message sending, payment operations, and notification sending, which are intercepted by the shadow agent or written to isolated storage in one or more ways. The target samples are selected using one or more methods: coverage optimization, stratified sampling, boundary value generation, cluster center selection, or risk-based active sampling.

10. The method according to claim 8, characterized in that, The determination of semantic consistency includes: Compare whether the target value read by the real consumer is consistent with the old value after semantic normalization; Compare whether cross-field invariant preservation, default values ​​triggered when a field is missing, and fallback paths are consistent; Compare the true / false results of key condition judgments, permission decisions, and state machine transitions to see if they are consistent.

11. The method according to claim 8, characterized in that, The step of deciding whether to reject, manually approve, or release the deterministic compatibility rule in a gray-scale manner based on the rule confidence level includes: Automatic publishing will be rejected when the rule confidence level is below a first threshold. When the rule confidence level is between the first threshold and the second threshold, manual approval is initiated. When the rule confidence score is higher than the second threshold and all high-risk invariants pass, gray-scale release is permitted, wherein the first threshold is less than the second threshold, and the rule confidence score is obtained from multiple factors including evidence strength, historical sample coverage, replay consistency, key consumer coverage, rule complexity, and ambiguity.

12. The method according to claim 8, characterized in that, The grayscale ratio publishing includes: The deterministic compatibility rules are bound to the applicable interface, service version, consumer version, traffic ratio, validity period, and rollback indicators and digitally signed. Only deterministic compatibility rules with valid signatures and matching scope are loaded at the compatibility execution layer; The deterministic compatibility rules are enabled and monitored in stages according to the first percentage, second percentage, third percentage and fourth percentage of matching traffic. The monitoring indicators include multiple indicators such as rule hit rate, conversion failure rate, field missing rate, consumer parsing anomaly, cross-field invariant failure, key business success rate and old version client error rate. The first percentage is less than the second percentage, the second percentage is less than the third percentage and the third percentage is less than the fourth percentage.

13. The method according to claim 1, characterized in that, The method further includes: Write manually confirmed field relationships, static validation results, reasons for replay success or failure, online grayscale metrics, and rollback reasons into the sample database; The candidate ranking model is updated with the final confirmed mapping as the label, and the risk model is updated with the semantic bias and rollback results as the label; Before the new model goes live, it is validated on the interface upgrade records that are later in time, without reducing the recall rate of high-risk changes.

14. An electronic device, characterized in that, include: A memory on which computer programs are stored; A processor for executing the computer program in the memory to implement the steps of the method according to any one of claims 1-13.

15. A non-transitory computer-readable storage medium having a computer program stored thereon, characterized in that, When executed by a processor, the program implements the steps of the method described in any one of claims 1-13.

16. A computer program product, comprising a computer program, characterized in that, When the computer program is executed by a processor, it implements the steps of the method according to any one of claims 1-13.

Images