Data platform interface service configuration methods, devices and related equipment

Abstract

This application relates to the field of data processing technology and can be applied to the fields of fintech and digital healthcare. It discloses a method, apparatus, and related equipment for configuring interface services on a data platform. The method includes: receiving and parsing an interface service configuration request to obtain a target interface identifier, interface service type, and call adaptation information; determining interface routing configuration, input parameter configuration, output parameter configuration, and call control configuration based on the target interface identifier; generating target routing configuration, target input parameter configuration, and target output parameter configuration by combining the interface service type and call adaptation information; generating call permission rules and call record rules based on the call control configuration and associating them to generate a target interface service configuration instance; and upon receiving an interface call request, completing route matching, permission verification, input parameter processing, interface call, return processing, and call record generation, and outputting the interface call processing result. This method can improve interface reusability, cross-system adaptability, and interface maintenance efficiency.

Description

Technical Field

[0001] This application relates to the field of data processing technology and can be applied to the fields of fintech / digital healthcare, and in particular to a data platform interface service configuration method, apparatus and related equipment. Background Technology

[0002] As enterprises increasingly integrate digital systems, data platforms typically need to handle data access requests from multiple business systems, terminal applications, and external collaboration systems simultaneously. These systems often differ in interface protocols, request fields, data formats, identity verification methods, return structures, and exception handling rules. In business scenarios such as fintech and healthcare, the same business object may need to be repeatedly queried, written to, updated, or synchronized by different systems, and there may be numerous cross-system data interaction needs between different business processes. For example, in fintech scenarios, user information, credit limit information, and transaction information may need to flow between multiple internal systems and external collaboration platforms; in healthcare scenarios, patient basic information, examination records, and settlement information may also need to be interacted between different business systems. In traditional technologies, interface services are usually designed separately for specific business systems or processes, and the interface structure is easily strongly bound to specific business tables, specific callers, or specific processing flows. When business fields are adjusted, system versions are upgraded, callers are added, or data flow rules change, the relevant interfaces often need to be modified and adapted separately, easily leading to frequent repetitive development, high interface maintenance costs, inconsistent calling rules, and low efficiency in exception location. Meanwhile, due to the lack of unified constraint boundaries and coordination rules between different interfaces, cross-platform calls are prone to issues such as inconsistent parameter meanings, incompatible returned data, unclear permission boundaries, and difficulty in controlling the scope of interface expansion. These issues can affect the stability of data flow, interface access efficiency, and subsequent expansion and maintenance capabilities of the data platform in a multi-system parallel environment. Summary of the Invention

[0003] The main technical problem addressed by the implementation method of this application is that traditional data platform interface services have high interface coupling, insufficient reusability, high cross-system adaptation costs, and low continuous maintenance efficiency in multi-system collaborative scenarios.

[0004] To solve the above-mentioned technical problems, the first technical solution adopted in the embodiments of this application is: providing a data platform interface service configuration method, including: receiving an interface service configuration request; parsing the interface service configuration request to obtain a target interface identifier, an interface service type, and call adaptation information; determining interface routing configuration, input parameter configuration, output parameter configuration, and call control configuration from an interface configuration library based on the target interface identifier; performing adaptation processing on the interface routing configuration, input parameter configuration, and output parameter configuration based on the interface service type and the call adaptation information to obtain a target routing configuration, a target input parameter configuration, and a target output parameter configuration; generating call permission rules and call record rules based on the call control configuration, and configuring the call permission rules, the call record rules, and the target input parameter configuration. The target routing configuration, the target input parameter configuration, and the target output parameter configuration are associated to generate a target interface service configuration instance. Upon receiving an interface call request for the target interface service configuration instance, the interface call request is route-matched based on the target routing configuration, and the interface call request is authorized based on the call permission rules. When the route matching is successful and the authorization verification passes, the input parameter data in the interface call request is processed based on the target input parameter configuration, and the interface call processing corresponding to the interface call request is executed to obtain processed data. The processed data is returned based on the target output parameter configuration to obtain the interface call processing result. The call process data is recorded according to the call record rules, and the interface call processing result is output.

[0005] To solve the above-mentioned technical problems, the second technical solution adopted in the embodiments of this application is: providing a data platform interface service configuration device, comprising: a configuration request parsing module, used to receive an interface service configuration request, parse the interface service configuration request, and obtain a target interface identifier, an interface service type, and call adaptation information; an interface configuration determination module, used to determine an interface routing configuration, input parameter configuration, output parameter configuration, and call control configuration from an interface configuration library based on the target interface identifier; an interface configuration adaptation module, used to perform adaptation processing on the interface routing configuration, the input parameter configuration, and the output parameter configuration based on the interface service type and the call adaptation information, to obtain a target routing configuration, a target input parameter configuration, and a target output parameter configuration; and a service instance generation module, used to generate call permission rules and call record rules based on the call control configuration, and to combine the call permission rules and the call record rules... Then, the target route configuration, the target input parameter configuration, and the target output parameter configuration are associated to generate a target interface service configuration instance; a call request verification module is used to perform route matching on the interface call request based on the target route configuration and perform permission verification on the interface call request based on the call permission rules after receiving an interface call request for the target interface service configuration instance; a call parameter processing module is used to process the input parameter data in the interface call request based on the target input parameter configuration and execute the interface call processing corresponding to the interface call request when the route matching is successful and the permission verification is passed, to obtain processed data; a call result output module is used to return the processed data based on the target output parameter configuration to obtain the interface call processing result, record the call process data according to the call record rules, and output the interface call processing result.

[0006] To solve the above-mentioned technical problems, the third technical solution adopted in the embodiments of this application is: to provide an electronic device, including: at least one processor; and a memory communicatively connected to the at least one processor; wherein the memory stores instructions that can be executed by the at least one processor, and the instructions are executed by the at least one processor to enable the at least one processor to execute the data platform interface service configuration method as described above.

[0007] To solve the above-mentioned technical problems, the fourth technical solution adopted in the embodiments of this application is: to provide a non-volatile computer-readable storage medium, wherein the non-volatile computer-readable storage medium stores computer-executable instructions, and when the computer-executable instructions are executed by an electronic device, the electronic device executes the data platform interface service configuration method as described above.

[0008] Unlike related technologies, this application unifies interface configuration, call adaptation, and call control, enabling interface services to move beyond fixed development methods tailored to single business systems or individual callers. Instead, it allows for the creation of executable interface service configuration instances based on a unified configuration. This approach ensures that interface routing, input parameter processing, output parameter processing, permission verification, and call logging work collaboratively within the same configuration instance, reducing mismatches caused by fragmented configurations of interface entry points, parameter rules, return rules, and control rules. When different systems employ different calling protocols, data formats, or interface versions, this application can adapt the configuration to create corresponding target configurations, reducing redundant development and manual modification costs. Furthermore, by performing route matching and permission verification before input parameter processing, interface calls, and result returns during the interface call process, the security, stability, and maintainability of interface calls are improved, thereby enhancing the data platform's interface reuse and cross-system adaptability in multi-system collaborative scenarios. Attached Figure Description

[0009] One or more embodiments are illustrated by way of example with reference to the accompanying drawings. These illustrations do not constitute a limitation on the embodiments. Elements having the same reference numerals in the drawings are denoted as similar elements. Unless otherwise stated, the figures in the drawings are not to be limited by scale.

[0010] Figure 1 This is a schematic diagram of the operating environment for the data platform interface service configuration method provided in the embodiments of this application.

[0011] Figure 2 This is a schematic diagram of the execution flow of the data platform interface service configuration method provided in the embodiments of this application.

[0012] Figure 3 This is a schematic diagram of the execution flow of the data platform interface service configuration method provided in this application embodiment, which performs adaptation processing on the configuration data.

[0013] Figure 4 This is a schematic diagram of the execution flow for generating a target interface service configuration instance in the data platform interface service configuration method provided in this application embodiment.

[0014] Figure 5 This is a schematic diagram of the system structure of the data platform interface service configuration device provided in the embodiments of this application.

[0015] Figure 6 This is a schematic diagram of the hardware structure of an electronic device for configuring the execution data platform interface service provided in the embodiments of this application. Detailed Implementation

[0016] To make the objectives, technical solutions, and advantages of this application clearer, the following detailed description is provided in conjunction with the accompanying drawings and embodiments. It should be understood that the specific embodiments described herein are merely illustrative and not intended to limit the scope of this application. Software tools, components, or servers not belonging to this company that appear in the embodiments of this application are merely illustrative examples and do not represent actual use.

[0017] It should be noted that, unless otherwise specified, the various features in the embodiments of this application can be combined with each other, all of which are within the protection scope of this application. Furthermore, although functional modules are divided in the device schematic diagram and a logical order is shown in the flowchart, in some cases, the steps shown or described may be performed in a different order than the module division in the device schematic diagram or the order in the flowchart.

[0018] Unless otherwise defined, all technical and scientific terms used in this specification have the same meaning as commonly understood by one of ordinary skill in the art to which this application belongs. The terminology used in this specification is for the purpose of describing particular embodiments only and is not intended to limit the scope of this application. The term "and / or" as used in this specification includes any and all combinations of one or more of the associated listed items.

[0019] To facilitate understanding of this embodiment, a detailed description of a data platform interface service configuration method disclosed in this application embodiment will be provided first. Please refer to [link to relevant documentation]. Figure 1 , Figure 1 This is a schematic diagram of the operating environment for the data platform interface service configuration method provided in the embodiments of this application, such as... Figure 1 As shown, the execution subject of the data platform interface service configuration method provided in this application embodiment is generally an electronic device with a certain computing power, such as a computer device. In some possible implementations, this data platform interface service configuration method can be implemented by the processor calling computer-readable instructions stored in the memory. Figure 1 The computer equipment mentioned can be a server. A server can be a standalone server or a cloud server that provides basic cloud computing services such as cloud services, cloud databases, cloud computing, cloud functions, cloud storage, network services, cloud communication, middleware services, domain name services, security services, content delivery networks (CDNs), and big data and artificial intelligence platforms. This can be understood as... Figure 1 The number of computer devices shown is merely illustrative and can be expanded in any number according to actual needs.

[0020] Please continue reading. Figure 2 , Figure 2This is a schematic diagram of the execution flow of the data platform interface service configuration method provided in the embodiments of this application, such as... Figure 2 As shown, it includes the following steps: S1. Receive the interface service configuration request, parse the interface service configuration request, and obtain the target interface identifier, interface service type, and call adaptation information.

[0021] Step S1 transforms externally submitted interface service configuration intentions into structured configuration criteria that the data platform can recognize and process internally. This primarily involves standardizing the identification of interface objects, service types, and calling environments within the configuration requests. The target interface identifier represents the interface object that needs configuration, preventing misuse of configurations between different interfaces. The interface service type represents different service types such as data query, data writing, state synchronization, and combined calls, facilitating subsequent determination of appropriate routing, input parameters, and output parameter adaptation methods. Call adaptation information represents differentiated call conditions such as caller type, call protocol, data format information, and interface version, enabling the same interface service to be configured and adapted for different systems or platforms. From an overall technical perspective, step S1 is the entry point in the interface service configuration process. This step first converts configuration requests from different sources and formats into a unified configuration identification result. Subsequently, based on the target interface identifier, the corresponding configuration can be determined from the interface configuration library, and combined with the interface service type and call adaptation information, configuration processing such as interface routing, input parameters, output parameters, and call control can be completed. For example, in fintech scenarios, a data platform may simultaneously connect to a user center, a credit management system, a risk identification system, and external partner platforms. Different callers may have different access protocols, field formats, and interface versions for the same type of data service. Step S1 can identify the data service object, service type, and call adaptation information corresponding to the configuration request, and subsequently generate a matching interface service configuration instance, reducing redundant interface development across different systems. In digital healthcare scenarios, a data platform may need to connect to registration systems, examination systems, settlement systems, and electronic medical record systems. Different systems may have different ways of calling patient basic data, examination record data, or settlement status data. Step S1 can clarify the medical data service object, service type, and call adaptation information corresponding to the interface to be configured, enabling subsequent configuration processing to achieve cross-system adaptation around a unified interface configuration logic, thereby improving the reusability and maintenance efficiency of interface services.

[0022] As an optional implementation, the execution process of step S1 may further include steps S11 to S16.

[0023] S11. Identify the request source of the interface service configuration request and obtain the request source information.

[0024] Step S11 identifies the source of the interface service configuration request to determine the calling entity, access channel, or system source corresponding to the configuration request. The request source information can reflect whether the configuration request originates from an internal business system, an external collaboration platform, a web application, an app, or a third-party system. For configuration requests carrying basic parameters, token information, timestamps, and other data can be used to further identify the request source and access identity, providing a foundation for subsequently determining the caller type, calling protocol, and permission boundaries.

[0025] S12. Extract the interface identifier field, service type field, and adaptation description field from the interface service configuration request to obtain candidate interface identifier, candidate service type, and candidate adaptation description information.

[0026] Step S12 extracts key fields from the interface service configuration request to obtain candidate data required for subsequent configuration processing. The interface identifier field can correspond to the interface ID or interface ID, reflecting the identification information of the interface to be configured. The service type field reflects the business processing mode of the interface service. The adaptation description field reflects adaptation content such as the calling environment, protocol format, interface version, or extended parameter extInfo. By extracting the above fields, the unstructured or semi-structured content in the configuration request can be converted into candidate information that can participate in rule validation and configuration matching.

[0027] S13. Verify the validity of the candidate interface identifier according to the preset interface identifier rules. When the candidate interface identifier passes the verification, determine the candidate interface identifier as the target interface identifier.

[0028] Step S13 verifies the validity of candidate interface identifiers according to preset interface identifier rules to determine whether they conform to the interface naming conventions, identifier formats, and interface registration rules in the data platform. When a candidate interface identifier passes the verification, it means that the candidate interface identifier can effectively point to the API interface object to be configured, and therefore the candidate interface identifier is determined as the target interface identifier. This step can reduce the processing risks caused by incorrect interface identifiers, interface object confusion, or invalid interface configurations.

[0029] S14. Match candidate service types according to the preset service type set, and determine the successfully matched candidate service types as interface service types.

[0030] Step S14 involves matching candidate service types with a preset service type set to determine the standard service category to which the current interface service belongs. The preset service type set can include types such as data query, data write, state synchronization, and combined calls, or it can correspond to abstract interface forms such as the general query interface `queryData` and the general write interface `writeData`. This step allows the service type description in the configuration request to be categorized into the service type system predefined by the data platform, enabling subsequent route adaptation, input parameter adaptation, and output parameter adaptation to be performed according to unified service type rules.

[0031] S15. Based on the request source information and candidate adaptation description information, determine the caller type, calling protocol, data format information, and interface version information.

[0032] Step S15 determines specific elements related to the call adaptation based on the request source information and candidate adaptation description information. The caller type can indicate whether the request initiator is a web application, an app, an internal system, or a third-party system. The call protocol can indicate whether the interface interaction uses RESTful, GraphQL, or other communication methods. The data format information can indicate the organization of the request and returned data, and may also include date and time formats such as ISO 8601. The interface version information can indicate the version range corresponding to the interface configuration. This step breaks down the adaptation description into multiple processable adaptation elements, facilitating the subsequent generation of call adaptation information.

[0033] S16. Generate call adaptation information based on the caller type, call protocol, data format information, and interface version information.

[0034] Step S16 combines the caller type, calling protocol, data format information, and interface version information to form call adaptation information that supports subsequent interface configuration adaptation processing. The call adaptation information centrally expresses the differences in protocol, format, version, and caller subject that need to be considered when the current interface service is directed to a specific calling environment. Through this step, subsequent interface routing configuration, input parameter configuration, and output parameter configuration can be specifically adapted based on the call adaptation information, enabling the same API interface service to generate matching configuration results for different systems, different terminals, and different protocol environments, thereby improving cross-platform adaptability and interface reuse capabilities.

[0035] As an example, in a fintech scenario, a data platform can receive interface configuration requests from user centers, credit management systems, risk identification systems, and external partner platforms. Different systems may carry different access identities, tokens, timestamps, interface IDs, service type descriptions, and extInfo. By identifying the request source and configuration semantics, the data platform can distinguish whether the request comes from an internal business system or an external collaboration platform, and further identify whether the request corresponds to a general query interface (queryData), a general write interface (writeData), or a state synchronization interface, thus forming an adaptation foundation that includes caller type, RESTful protocol, data format information, and interface version information. In digital finance scenarios, data platforms may simultaneously provide API interface configuration capabilities to web, app, open platforms, and third-party service providers. Different callers may use different field names, version identifiers, and date formats, such as the ISO8601 format. By standardizing and identifying the interface object, service type, and adaptation description in the interface configuration request, the data platform can convert configuration requests from different sources into a unified interface adaptation basis. This avoids the need for repeated configuration of the same financial data service due to differences in calling terminals, protocol formats, or interface versions, thereby improving the accuracy of interface configuration and cross-platform reusability.

[0036] Through steps S11 to S16, interface service configuration requests from different sources and in different formats can be converted into call adaptation information that is uniformly recognized within the data platform. This standardizes the representation of interface objects, service types, call subjects, call protocols, data formats, and interface versions in the configuration requests. This process reduces identification biases caused by semantic inconsistencies in configuration requests, minimizes issues such as incorrect interface identification, misjudgment of service types, and missing adaptation information, and provides an accurate data foundation for subsequent interface configuration library queries, route adaptation, input parameter adaptation, output parameter adaptation, and call control configuration. Simultaneously, this process masks differences in access channels, protocol formats, and version descriptions among different callers, enabling the same interface service to complete subsequent configuration processing based on unified adaptation information. This improves the accuracy of interface service configuration, cross-system adaptability, and interface reusability.

[0037] S2. Based on the target interface identifier, determine the interface routing configuration, input parameter configuration, output parameter configuration, and call control configuration from the interface configuration library.

[0038] Step S2 locates the basic configuration data corresponding to the current interface object from the interface configuration library using the target interface identifier, ensuring a unified data source for subsequent configuration processing. The interface configuration library can be understood as a centralized storage space within the data platform that maintains interface configuration resources. Interface routing configuration reflects the interface access entry point and request matching method; input parameter configuration reflects the organization of input data in the call request; output parameter configuration reflects the organization of the interface processing results; and call control configuration reflects the permission boundaries and recording rules during the interface call process. Through step S2, the system does not need to redefine the basic interface information for different callers; instead, it first determines a reusable configuration base from the unified configuration library. For example, in a fintech scenario, the same credit limit data service may be called by multiple internal systems and external partner platforms. Step S2 can find the corresponding route, parameters, and control configuration based on the target interface identifier. In a digital healthcare scenario, the same patient information service may be called by the registration system, examination system, and settlement system. Step S2 can first determine the basic configuration corresponding to the patient information service, and then perform differentiated adaptation according to different calling environments.

[0039] As an optional implementation, the execution process of step S2 may further include steps S21 to S26.

[0040] S21. Query the interface configuration index table in the interface configuration library based on the target interface identifier to obtain the candidate interface configuration record associated with the target interface identifier.

[0041] In step S21, the target interface identifier is used to index and locate the interface configuration data in the interface configuration library, thereby narrowing the search scope of the interface configuration data. The interface configuration index table can be understood as a mapping table between interface identifiers and configuration records, which can associate interface objects with their corresponding configuration records. This step avoids performing a full search in the interface configuration library, improves configuration lookup efficiency, and ensures that the configuration records read subsequently correspond to the current target interface object.

[0042] S22. Verify the configuration status of the candidate interface configuration records to obtain valid interface configuration records.

[0043] Step S22 verifies the configuration status of candidate interface configuration records to filter out unavailable, unpublished, disabled, or version-abnormal records. Although candidate interface configuration records are associated with the target interface identifier, not all of them can participate in the current interface service configuration process. Therefore, it is necessary to further determine whether the configuration record is in a valid state. This step avoids carrying invalid, historical, or abnormal configurations into subsequent adaptation processes, improving the reliability of the interface service configuration results.

[0044] S23. Determine the target interface configuration version from the valid interface configuration records based on the interface service type and call adaptation information.

[0045] Step S23 involves combining the interface service type and call adaptation information to determine the target interface configuration version from valid interface configuration records. Different interface service types may correspond to different configuration versions, and different callers, call protocols, data format information, or interface version information may also correspond to different configuration branches. This step allows for the selection of a configuration version that matches the current service type and call environment from multiple valid configuration records, avoiding mismatches in routing, parameters, or call control configurations due to inaccurate version selection.

[0046] S24. Based on the target interface configuration version, read the routing configuration record, input parameter configuration record, output parameter configuration record, and call control configuration record associated with the target interface identifier from the interface configuration library.

[0047] In step S24, the corresponding routing configuration record, input parameter configuration record, output parameter configuration record, and call control configuration record are read according to the target interface configuration version. Once the target interface configuration version is determined, the interface configuration library can read multiple configuration records associated with the target interface identifier according to the version dimension. The routing configuration record reflects the interface access entry point, the input parameter configuration record reflects the organization method of request parameters, the output parameter configuration record reflects the organization method of returned results, and the call control configuration record reflects the rules for permissions and call process recording. This step provides a complete configuration data foundation for subsequent interface adaptation and instance generation.

[0048] S25. Perform consistency verification on the routing configuration record, input parameter configuration record, output parameter configuration record, and call control configuration record.

[0049] Step S25 performs a consistency check on the routing configuration record, input parameter configuration record, output parameter configuration record, and call control configuration record to determine whether each type of configuration record belongs to the same interface object, the same configuration version, and the same adaptation range. Since these configuration records may be maintained separately, inconsistencies in configuration version, interface identifier, or adaptation range may lead to problems such as mismatched routing entry points and parameter rules, inconsistent return processing rules, or call control failures in subsequently generated interface service configuration instances. This step allows for the early detection of configuration association anomalies before the configuration instance is generated.

[0050] S26. When the association consistency verification passes, the routing configuration record is determined as the interface routing configuration, the input parameter configuration record is determined as the input parameter configuration, the output parameter configuration record is determined as the output parameter configuration, and the call control configuration record is determined as the call control configuration.

[0051] In step S26, when the consistency verification passes, various configuration records are identified as the interface routing configuration, input parameter configuration, output parameter configuration, and call control configuration required for subsequent processing. This step is equivalent to formally confirming the verified configuration records, ensuring that subsequent adaptation processing, call control rule generation, and interface service configuration instance generation are all based on the same set of valid and consistent configuration data. This step guarantees a stable configuration association between interface routing, input parameters, output parameters, and call control, thereby improving the consistency and maintainability of the interface service configuration process.

[0052] As an example, in a fintech scenario, the data platform can pre-maintain interface configuration records for services such as credit limit data, user data, and risk identification. When a target interface identifier points to a specific credit limit data service, the system can first locate multiple configuration records associated with that interface object through the interface configuration index table, and filter out deactivated, unpublished, or version-abnormal configuration records. Then, it combines the interface service type, caller type, calling protocol, and interface version information to select the target interface configuration version suitable for the current calling environment. For instance, although the internal credit limit management system and external partner platforms may call the same credit limit data service, their corresponding routing entry points, input parameter fields, output parameter formats, and call control boundaries may differ. Therefore, it is necessary to read a set of routing configuration records, input parameter configuration records, output parameter configuration records, and call control configuration records corresponding to the target interface configuration version from the interface configuration library, and perform consistency checks on the interface identifiers, version information, and adaptation scope among these configuration records to avoid situations where the routing entry point belongs to a new version while the parameter configuration still belongs to an old version. In digital healthcare scenarios, data platforms can pre-maintain interface configuration records for services such as basic patient information, examination records, and settlement status. When different medical business systems call the same basic patient information service, the system can select the corresponding configuration version based on the target interface identifier and the current call adaptation information, and read the routing, input parameters, output parameters, and call control configuration under the same version. This ensures that when the registration system, examination system, or settlement system calls the same type of medical data service, the interface entry, parameter rules, return structure, and access control remain consistent, reducing the risk of abnormal data calls caused by configuration mismatch.

[0053] Through steps S21 to S26, the process of obtaining interface configuration data is transformed from simple configuration reading into a step-by-step filtering process based on interface identifier, configuration status, service type, call adaptation information, and configuration version. This improves the accuracy and stability of interface configuration determination. This process avoids invalid configurations, disabled configurations, historical version configurations, or version-mismatched configurations from participating in subsequent interface service configurations, reducing the risk of mismatches between routing configurations, input parameter configurations, output parameter configurations, and call control configurations. Simultaneously, by performing consistency checks on multiple types of configuration records, it ensures that subsequent adaptation processing and instance generation are performed based on the same interface object, the same configuration version, and the same adaptation scope, maintaining a unified configuration relationship between interface routing, parameter processing, return processing, and call control. Therefore, this process improves interface configuration retrieval efficiency, the accuracy of configuration version selection, and the reliability and maintainability of interface service configuration instances.

[0054] S3. Based on the interface service type and call adaptation information, adapt the interface routing configuration, input parameter configuration and output parameter configuration to obtain the target routing configuration, target input parameter configuration and target output parameter configuration.

[0055] Step S3 adapts the interface routing configuration, input parameter configuration, and output parameter configuration to the calling environment, enabling the same basic interface configuration to generate a target configuration result suitable for the current interface service type and call adaptation information. The interface service type can affect the interface processing method; for example, the parameter processing logic for query services, write services, synchronization services, or combined call services differs. Call adaptation information reflects the differences in protocol, version, data format, and call entry point between different callers. Through step S3, the system can generate target routing configuration, target input parameter configuration, and target output parameter configuration without changing the basic interface configuration, thereby reducing redundant development caused by differences in protocol, fields, and versions between different systems. For example, in a fintech scenario, internal systems and external cooperation platforms may use different interface versions or field formats; step S3 can generate target input and output parameter configurations matching different callers. In a digital healthcare scenario, different medical business systems may use different formats for patient information fields and examination record fields; step S3 can adapt the fields and return structures based on the call adaptation information.

[0056] As an alternative implementation method, please continue reading. Figure 3 , Figure 3 This is a schematic diagram of the execution flow of the data platform interface service configuration method provided in this application embodiment, which performs adaptation processing on the configuration data. Figure 3 As shown, the specific steps may include S31 to S36.

[0057] S31. Based on the interface service type, determine the routing adaptation strategy, input parameter adaptation strategy, and output parameter adaptation strategy corresponding to the interface service type.

[0058] Step S31 determines the corresponding adaptation strategy based on the interface service type, ensuring that subsequent routing, input parameter, and output parameter processing are executed according to the actual processing form of the interface service. Different interface service types may differ in access entry points, parameter structures, and return structures. For example, query services focus more on query conditions and return fields, write services focus more on the completeness of input fields and processing result feedback, and combined call services focus more on parameter connection and result integration between multiple interfaces. This step helps determine the routing adaptation strategy, input parameter adaptation strategy, and output parameter adaptation strategy that match the interface service type, providing a strategic basis for subsequently generating target route configuration, target input parameter configuration, and target output parameter configuration.

[0059] S32. Based on the calling protocol and interface version information in the calling adaptation information, adapt the access path, request method and version identifier in the interface routing configuration according to the routing adaptation strategy to obtain the target routing configuration.

[0060] In step S32, the interface routing configuration is adapted based on the calling protocol and interface version information to match the interface access entry point with the current calling environment. The calling protocol can affect the interface access method and request organization, while the interface version information can affect the version identifier or route branch selection in the access path. By adjusting the access path, request method, and version identifier according to the routing adaptation strategy, the target routing configuration can accurately reflect the interface entry points that the current caller can access, avoiding the situation where interface call requests cannot correctly hit the target interface service due to protocol or version differences.

[0061] S33. Based on the caller type and data format information in the call adaptation information, adapt the parameter item activation status, parameter source and parameter format in the input parameter configuration according to the input parameter adaptation strategy to obtain the target input parameter configuration.

[0062] Step S33 adapts the input parameter configuration based on the caller type and data format information, enabling the input data in the interface call request to be identified and processed according to the current caller's access characteristics. The caller type reflects whether the calling entity belongs to an internal system, external platform, web client, or app client, etc. The data format information reflects the field format, data type, and organization of the input parameter data. By adjusting the parameter item activation status, parameter source, and parameter format according to the input parameter adaptation strategy, the target input parameter configuration can accurately limit the input parameters that need to be collected, converted, and verified in the current calling environment, reducing the impact of field and format differences between different systems on interface call processing.

[0063] S34. Based on the data format information and interface version information in the call adaptation information, adapt the return fields, field mapping relationships and return formats in the output parameter configuration according to the output parameter adaptation strategy to obtain the target output parameter configuration.

[0064] In step S34, the output parameter configuration is adapted based on the data format information and interface version information, ensuring that the interface processing result is output according to a return structure recognizable by the current caller. Different callers or different interface versions may correspond to different return field ranges, field naming conventions, field mapping relationships, and return formats. By adjusting the return fields, field mapping relationships, and return formats according to the output parameter adaptation strategy, the target output parameter configuration can be matched with the current calling environment, avoiding inconsistencies between the interface processing data and the caller's received format, and improving the compatibility of the interface return results.

[0065] S35. Perform an adaptation consistency check on the target route configuration, target input parameter configuration, and target output parameter configuration.

[0066] Step S35 performs a consistency check on the target route configuration, target input parameter configuration, and target output parameter configuration to determine whether the three types of target configurations correspond to the same interface service type, the same call adaptation information, and the same interface version range. Since the route configuration, input parameter configuration, and output parameter configuration complete the adaptation processing from different dimensions, inconsistencies in adaptation range or versions among the three may result in the interface request hitting the route but the parameter processing rules not matching, or the processed data not being output in the correct return format. This step helps to identify the risk of mismatch between adaptation configurations before generating the target interface service configuration instance.

[0067] S36. When the adaptation consistency verification passes, determine the target route configuration, target input parameter configuration, and target output parameter configuration to generate the target interface service configuration instance.

[0068] In step S36, after the adaptation consistency verification passes, the target route configuration, target input parameter configuration, and target output parameter configuration are confirmed, making these three types of target configurations the basis for subsequently generating the target interface service configuration instance. This step indicates that the route entry point, input parameter processing rules, and output result processing rules have completed collaborative adaptation for the current calling environment. Subsequently, the three types of configurations can be further associated with calling permission rules and calling record rules to form an interface service configuration instance capable of handling actual interface call requests.

[0069] As an example, in fintech scenarios, a data platform can simultaneously provide interface services for credit limit data, user data, or risk identification data to both internal business systems and external partner platforms. Different callers may use RESTful protocols, different interface versions, and different field formats. For query-type interface services, the data platform can choose adaptation strategies biased towards query path matching, query condition identification, and return field filtering, enabling internal systems and external platforms to obtain matching access paths, input parameter structures, and return formats when calling the same type of data service. For write-type interface services, the data platform can choose adaptation strategies biased towards parameter integrity, field format conversion, and processing result feedback, ensuring that data submitted by different callers can be converted into a parameter structure uniformly recognized within the platform. In digital healthcare scenarios, a data platform can provide interface services such as patient basic information, examination records, or settlement status to registration systems, examination systems, settlement systems, and electronic medical record systems. Different systems may correspond to different data formats, version identifiers, and return field ranges. By coordinating and adapting routing, input parameters, and output parameters, different medical business systems can both hit the correct interface entry according to their respective access methods and complete parameter identification and return result conversion according to unified rules when calling the same type of medical data services, thereby reducing interface call anomalies caused by differences in protocols, versions, and field formats.

[0070] Through steps S31 to S36, interface routing, input parameters, and output results are no longer bound to a single calling scenario in a fixed manner. Instead, they form a mutually matching target configuration based on the interface service type and call adaptation information, thereby improving the adaptability of the interface service under different calling protocols, interface versions, caller types, and data formats. This process can coordinately adjust the routing entry point, parameter processing rules, and return processing rules, reducing problems such as inconsistencies between interface access entry points and parameter rules, mismatches between input fields and service processing logic, and incompatibility between processing results and caller receiving formats. Simultaneously, through adaptation consistency verification, mismatch risks between target routing configuration, target input parameter configuration, and target output parameter configuration can be detected before the interface service configuration instance is generated, ensuring that subsequent interface call requests can complete route hits, parameter identification, and result return according to a unified configuration relationship. Therefore, this process can reduce cross-system interface adaptation costs and improve the reusability, compatibility, and stability of interface configuration.

[0071] S4. Based on the call control configuration, generate call permission rules and call record rules, and associate the call permission rules, call record rules, target route configuration, target input parameter configuration and target output parameter configuration to generate a target interface service configuration instance.

[0072] Step S4 associates the call control configuration with the already adapted target route configuration, target input parameter configuration, and target output parameter configuration to form a target interface service configuration instance that can be actually invoked. The focus of this step is not just on generating call permission rules and call record rules, but on integrating permission verification, call recording, route matching, parameter processing, and return processing into a single interface service configuration instance, transforming the interface service from a fragmented configuration state to an executable configuration instance state. Call permission rules can limit the access boundaries of different callers to the interface service, and call record rules can standardize the recording method of interface call process data. After being associated with the target route configuration, target input parameter configuration, and target output parameter configuration, they can ensure that the interface call process is executed according to the same configuration instance. For example, in a fintech scenario, different external cooperation platforms may have different access permissions to credit limit data or risk data; step S4 can bind the permission boundaries to the interface configuration instance. In a digital healthcare scenario, different medical business systems may have different access permissions to patient basic data and examination result data; step S4 can uniformly constrain the call entry point, parameter processing, and call process recording through the configuration instance.

[0073] As an alternative implementation method, please continue reading. Figure 4 , Figure 4 This is a schematic diagram of the execution flow of generating a target interface service configuration instance in the data platform interface service configuration method provided in this application embodiment, as shown below. Figure 4 As shown, the specific steps may include S41 to S46.

[0074] S41. Extract the permission control data and record control data corresponding to the target interface identifier from the call control configuration.

[0075] Step S41 extracts control data corresponding to the target interface identifier from the call control configuration, enabling a clear correspondence between the call control content and the current interface object. The access control data reflects which callers are allowed to access the current interface service, and the service scope accessible to different callers. The record control data reflects the process information and recording methods that need to be retained during the interface call process. This step prevents the mixing of access control and record control between different interfaces, providing a clear data foundation for subsequent rule generation.

[0076] S42. Based on the access control data, interface service type, and call adaptation information, generate call permission rules for verifying the permissions of interface call requests.

[0077] Step S42 generates call permission rules based on permission control data, interface service type, and call adaptation information. This ensures that permission verification does not rely solely on the identity of a single caller, but rather on a comprehensive judgment considering the interface service type, call environment, and adaptation conditions. The interface service type can affect the granularity of call permission control, and call adaptation information can reflect differences in caller type, call protocol, data format information, and interface version information. This step ensures that the call permission rules match the actual call environment of the current interface service configuration instance, improving the accuracy of interface access control.

[0078] S43. Based on the record control data, generate call record rules for recording the call process data of interface call requests.

[0079] Step S43 generates call record rules based on the record control data, enabling process data during the interface call to be recorded in a preset manner. The call record rules can limit the triggering time, content scope, and association method for recording call process data, ensuring that key process information generated during the interface call processing is stably preserved. This step provides a data foundation for subsequent call tracing, anomaly analysis, and operation and maintenance.

[0080] S44. Configure the call permission rule as the pre-verification rule corresponding to the target route configuration.

[0081] Step S44 configures the access permission rules to match the pre-verification rules corresponding to the target route configuration. This ensures that API call requests undergo permission verification after hitting the target route before proceeding to subsequent parameter processing and API call processing. This configuration method binds the access entry point and access control, preventing requests from entering the subsequent processing chain simply because the route matches successfully. This step improves the security and standardization of the API call process.

[0082] S45. Configure the target input parameter configuration and target output parameter configuration as the parameter processing rules and return processing rules corresponding to the target routing configuration, respectively.

[0083] Step S45 configures the target input parameter configuration and target output parameter configuration to the parameter processing rules and return processing rules corresponding to the target route configuration, respectively, so that the interface call request can complete the input data processing and output data processing according to unified rules under the target route. The target input parameter configuration constrains the parameter extraction, mapping, format conversion, and validation process in the interface call request. The target output parameter configuration constrains the field mapping, format encapsulation, and return structure of the processed data. Through this step, a stable configuration association can be formed between the request entry, input processing, and return processing under the same target route.

[0084] S46. Configure the call recording rules as the process recording rules corresponding to the interface call processing, and generate the target interface service configuration instance.

[0085] Step S46 configures the call recording rules as the process recording rules corresponding to the interface call processing, and generates a target interface service configuration instance. This step integrates the pre-validation rules, parameter processing rules, return processing rules, and process recording rules into the same interface service configuration instance, transforming the interface service from a scattered configuration state to an executable, instantiated configuration state. Through this step, subsequent interface call requests can complete route matching, permission verification, parameter processing, interface call, return processing, and process recording according to the same configuration instance, thereby improving the consistency and maintainability of the interface service configuration.

[0086] As an example, in a fintech scenario, a data platform can provide interface services to internal credit limit management systems, risk identification systems, and external partner platforms. Different callers may have different access boundaries for credit limit data, user data, or risk characteristic data. The data platform can extract permission control data and record control data corresponding to the target interface identifier from the call control configuration, and generate call permission rules by combining the interface service type, caller type, call protocol, and interface version information. This ensures that external partner platforms, even after hitting the target route, still need to undergo pre-access permission verification before proceeding to parameter processing and interface call processing. Simultaneously, the target input parameter configuration and target output parameter configuration can be bound to the target route configuration, enabling requests under the same route entry point to be executed according to matching parameter processing rules and return processing rules, and recording interface call process data through call record rules. In digital healthcare scenarios, data platforms can provide interface services such as patient basic information, examination records, or settlement status to registration systems, examination systems, settlement systems, and electronic medical record systems. Different systems may have different access permissions and call record specifications for medical data. Data platforms can centrally configure access control, parameter processing, return processing, and process recording into the same target interface service configuration instance. This allows interface call requests to complete access control before entering actual data processing, and to complete parameter processing, result return, and process recording according to unified rules during the call process. This reduces problems such as chaotic interface call permissions, scattered processing rules, and difficulty in tracking the call process.

[0087] Through steps S41 to S46, interface call control, routing entry, input parameter processing, output parameter processing, and process logging can be integrated into the same target interface service configuration instance. This transforms the interface service from being driven solely by individual routing or parameter configurations into a complete call chain encompassing pre-validation, parameter processing, return processing, and process logging. This process binds call permission rules to the target routing configuration, ensuring that interface call requests undergo permission verification before entering parameter processing and interface call processing, reducing the risk of unauthorized or erroneous calls entering subsequent processing flows. Simultaneously, the target input parameter configuration and target output parameter configuration are attached to the target routing configuration as parameter processing rules and return processing rules, respectively. This ensures stable input processing logic and output return logic corresponding to the same routing entry, reducing inconsistencies caused by scattered routing, parameter, and return configurations. Furthermore, by configuring call logging rules as process logging rules, traceable call process data can be retained during interface call processing, improving the efficiency of anomaly localization, call auditing, and operational maintenance. Therefore, this process enhances the integrity, execution consistency, and maintainability of the target interface service configuration instance.

[0088] S5. After receiving the interface call request for the target interface service configuration instance, perform route matching on the interface call request based on the target routing configuration, and perform permission verification on the interface call request based on the call permission rules.

[0089] In step S5, after the target interface service configuration instance receives the interface call request, it identifies the entry point and determines the call eligibility. Route matching primarily determines whether the interface call request matches the access entry point corresponding to the target route configuration, while permission verification primarily determines whether the current caller meets the access conditions limited by the call permission rules. Through step S5, the system can complete the pre-judgment of request entry point and call permission before entering specific parameter processing and interface call processing, preventing invalid or unauthorized requests from continuing into subsequent processing links. For example, in a fintech scenario, when an external cooperation platform initiates a credit limit data access request, step S5 can first determine whether the request path and request method match the target route configuration, and then determine whether the caller has the permission to access the corresponding service. In a digital healthcare scenario, when an inspection system or settlement system initiates a patient information call request, step S5 can first confirm whether the request matches the correct patient information service entry point, and then confirm whether the caller has the corresponding data call permission.

[0090] As an optional implementation, the execution process of step S5 may further include steps S51 to S55.

[0091] S51. Extract request routing information and caller verification information from the interface call request.

[0092] Step S51 extracts request routing information and caller verification information from the interface call request, enabling subsequent processing to determine the request entry point and caller identity separately. Request routing information may include access path, request method, interface version identifier, etc., while caller verification information may include caller identifier, authentication token, signature information, or other identity verification data. This step separates the routing matching elements and permission verification elements from the interface call request, providing a data foundation for subsequent route matching and pre-verification.

[0093] S52. Match the requested routing information with the target routing configuration to obtain the routing matching result.

[0094] Step S52 involves matching the request routing information with the target routing configuration to determine whether the current interface call request corresponds to a valid access entry point in the target interface service configuration instance. The target routing configuration can limit routing conditions such as access path, request method, and version identifier. The routing matching result indicates whether the interface call request hits the corresponding interface entry point. This step prevents interface call requests that do not conform to the target routing configuration from entering subsequent permission verification and parameter processing flows, improving the accuracy of interface call entry point identification.

[0095] S53. When the route matching result indicates that the route matching is successful, the pre-verification rule corresponding to the target route configuration is invoked.

[0096] In step S53, when the route matching result indicates a successful route match, the pre-verification rule corresponding to the target route configuration is invoked, ensuring that the interface call request undergoes access control judgment before entering the parameter processing flow. The pre-verification rule originates from the call permission rule bound to the target route configuration in the target interface service configuration instance, and this rule corresponds to a specific route entry point. This step ensures that route matching and permission verification are sequentially linked, preventing requests from directly entering interface call processing simply because they match an access entry point.

[0097] S54. Based on the pre-verification rules, perform permission verification on the caller's verification information, interface service type, and call adaptation information.

[0098] Step S54, based on pre-verification rules, performs permission verification on the caller's authentication information, interface service type, and call adaptation information, ensuring that permission judgment considers the caller, service type, and call environment simultaneously. The caller's authentication information reflects the caller's identity; the interface service type reflects the service type corresponding to the current request, such as data query, data write, state synchronization, or combined calls; and the call adaptation information reflects differences in call protocol, data format, and interface version. This step improves the granularity of interface access control and reduces the risk of out-of-bounds calls caused by a correct caller identity but a mismatch in service type or adaptation conditions.

[0099] S55. When the permission verification is successful, the interface call request will be transferred to the parameter processing flow corresponding to the target input parameter configuration.

[0100] In step S55, when the permission verification passes, the interface call request is transferred to the parameter processing flow corresponding to the target input parameter configuration, allowing the interface call request to enter subsequent processing stages such as input parameter extraction, field mapping, format conversion, and validity verification. This step indicates that the interface call request has completed entry matching and access control judgment, and the input parameter data in the request can be configured according to the target input parameter configuration. Through this step, it is ensured that only interface call requests with successful route matching and permission verification enter the parameter processing chain, thereby improving the security and orderly processing of the interface call process.

[0101] As an example, in a fintech scenario, when an external partner platform or internal business system initiates an API call request for credit limit data, user data, or risk characteristic data, the data platform can first parse the access path, request method, API version identifier, caller identifier, token, and signature information from the request. It then matches the access path, request method, and API version identifier against the target routing configuration. When the request matches the target routing configuration, the data platform further invokes the pre-verification rules bound to that configuration to comprehensively verify the caller's identity, service type, calling protocol, data format information, and API version information, preventing the caller from entering the subsequent processing flow solely based on a correct access point. When the verification result indicates that the caller has the necessary permissions to access the current API service, the API call request then enters the parameter processing flow corresponding to the target input parameter configuration, ensuring that the API call process is executed in the order of "entry point matching, permission confirmation, and parameter processing." In digital healthcare scenarios, when registration, examination, settlement, or electronic medical record systems call interfaces for patient basic information, examination records, or settlement status, the data platform can first identify the request entry point and the identity of the caller, and then determine whether the current business system has the corresponding access permissions for medical data services based on pre-verification rules. Only after the verification is passed will subsequent processing flows such as parameter extraction, field mapping, and format conversion be entered, thereby reducing the risk of erroneous entry points, unauthorized calls, and invalid requests entering the interface processing chain.

[0102] Through steps S51 to S55, request entry identification and call permission judgment can be completed before the interface call request enters the parameter processing flow, ensuring that the interface call process follows an execution order of route matching, pre-verification, and parameter processing. This process matches request routing information with the target route configuration, ensuring that only interface call requests that match the target access entry point enter the permission verification stage, reducing interference from invalid paths, incorrect request methods, or version mismatch requests on subsequent processing flows. Simultaneously, by comprehensively verifying the caller's authentication information, interface service type, and call adaptation information through pre-verification rules, coarse-grained judgments based solely on the caller's identity can be avoided, improving the accuracy and granularity of interface access control. After permission verification passes, the interface call request is then transferred to the parameter processing flow corresponding to the target input parameter configuration, ensuring that subsequent parameter extraction, field mapping, format conversion, and validity verification are all performed on authorized requests with successful route matching. Therefore, this process improves the accuracy of interface call entry point identification, the reliability of permission verification, and the security and orderliness of the interface call processing chain.

[0103] S6. When the route is successfully matched and the permission verification is passed, the parameter data in the interface call request is processed based on the target input parameter configuration, and the interface call processing corresponding to the interface call request is executed to obtain the processed data.

[0104] In step S6, after successful route matching and permission verification, the input parameter data in the interface call request is configured, and the corresponding interface call is executed based on the processed input parameter data. The target input parameter configuration can constrain which parameter items need to be extracted, how parameter fields are mapped, how parameter formats are converted, and how parameter validity is determined. Through step S6, raw input parameter data from different callers can be converted into standardized input parameter data that can be uniformly recognized within the data platform, thereby driving subsequent interface call processing. This process can reduce the impact of differences in field naming, parameter formats, and data organization methods between different systems on the interface execution process. For example, in a fintech scenario, user identifiers, credit limit objects, or business transaction fields submitted by different systems may have naming differences; step S6 can complete field mapping and format conversion based on the target input parameter configuration. In a digital healthcare scenario, patient identifiers, examination items, or settlement status fields submitted by different systems may have format differences; step S6 can convert these input parameter data into unified standard input parameter data before executing the interface call processing.

[0105] As an optional implementation, the execution process of step S6 may further include steps S61 to S65.

[0106] S61. Based on the target input parameter configuration, determine the input parameter data to be processed corresponding to the enabled parameter item from the interface call request.

[0107] Step S61 identifies the input parameter data that needs to be processed in the current interface call request based on the target input parameter configuration. The target input parameter configuration may include the parameter item's enable status, parameter source, parameter type, default value, and parameter extraction rules. Through this step, data corresponding to enabled parameter items can be filtered from the original parameters carried in the interface call request, preventing disabled, redundant, or irrelevant parameters from entering the subsequent processing flow, and ensuring that subsequent field mapping and format conversion are performed around valid input parameter data.

[0108] S62. Based on the parameter mapping relationship in the target input parameter configuration, perform field mapping on the input parameter data to be processed to obtain the mapped input parameter data.

[0109] In step S62, the input parameter data to be processed is mapped to fields according to the parameter mapping relationship in the target input parameter configuration. Different callers may use different field names or different parameter organization methods. For example, data with the same business meaning may correspond to different field identifiers in different systems. Through this step, the fields on the caller side can be converted into a field structure that is uniformly recognized within the data platform, so that interface call requests from different sources can be converted into a unified parameter expression system, reducing the impact of field naming differences on interface call processing.

[0110] S63. Based on the parameter format rules and parameter validation rules in the target input parameter configuration, perform format conversion and validity validation on the mapped input parameter data to obtain standard input parameter data.

[0111] Step S63 further processes the mapped input parameter data according to parameter format rules and parameter validation rules. Parameter format rules can specify field type, date format, numeric format, character encoding, or data structure format. Parameter validation rules can specify mandatory field validation, value range validation, length validation, enumeration value validation, or related field validation. Through format conversion and validity validation, the mapped input parameter data can be organized into standard input parameter data that conforms to the interface processing strategy input specifications, reducing interface processing failures caused by incorrect parameter formats or abnormal parameter content.

[0112] S64. When the standard input parameter data passes the verification, determine the interface processing strategy corresponding to the standard input parameter data based on the interface service type.

[0113] In step S64, after the standard input parameter data passes verification, the corresponding interface processing strategy is determined based on the interface service type. The interface service type reflects the service type corresponding to the current interface call request, such as data query, data writing, state synchronization, or combined calls. Different service types correspond to different data processing logic and execution paths. This step establishes a correspondence between the standard input parameter data and the interface processing strategy suitable for the current service type, avoiding the use of mismatched processing strategies to execute interface call requests.

[0114] S65. Run the interface processing strategy, execute the interface call processing corresponding to the interface call request based on the standard input parameter data, and obtain the processed data.

[0115] Step S65 executes the interface processing strategy and performs the corresponding interface call processing based on the standard input parameter data. The standard input parameter data has undergone field mapping, format conversion, and validity validation, and can be used as input data for the interface processing strategy in subsequent business processing or data interaction. Through this step, interface call requests from different callers can be converted into executable processing procedures within the data platform, and corresponding processing data can be output, providing a data foundation for subsequent return processing based on the target output parameter configuration.

[0116] As an example, in a fintech scenario, when different business systems or external partner platforms call interfaces for credit limit data, user data, or risk characteristic data, the interface call request may carry multiple parameters such as caller identifier, token, timestamp, user identifier, business transaction number, and target data type. Some of these parameters may only be applicable to a specific caller or a specific interface service type. The data platform can first filter the parameters actually enabled by the current interface based on the target input parameter configuration, excluding irrelevant parameters. Then, based on the parameter mapping relationship, it converts the fields submitted by different callers into a field structure that is uniformly recognized within the platform. For example, it maps user ID fields, business ID fields, or data object fields from different systems to standard fields. Subsequently, the data platform can complete format conversion and validity verification according to parameter format and validation rules, so that input parameter data from different sources is organized into standard input parameter data. Based on the interface service type, it selects interface processing strategies such as query, write, status synchronization, or combined calls, and finally executes the corresponding interface call processing based on the standard input parameter data. In digital healthcare scenarios, when registration, examination, settlement, or electronic medical record systems call interfaces for patient basic information, examination records, or settlement status, different systems may use different patient identification fields, examination item fields, date formats, or status fields. The data platform can complete parameter filtering, field mapping, format conversion, and validity verification through target input parameter configuration, so that interface call requests from different medical business systems are converted into unified standard input parameter data. Then, according to the interface service type, the corresponding data query, data writing, or status synchronization processing is performed, thereby reducing the impact of field differences, format differences, and invalid parameters on the interface call processing process.

[0117] Through steps S61 to S65, the raw input parameter data submitted by different callers can be converted into standard input parameter data uniformly recognized within the data platform. This eliminates the direct dependence of interface call processing on the caller's field naming, parameter format, and data organization. This process filters valid parameters based on the target input parameter configuration, reducing interference from redundant, disabled, or irrelevant parameters. Furthermore, through field mapping, format conversion, and validity validation, it mitigates the risk of interface processing failures due to field differences, inconsistent formats, or abnormal parameters. Simultaneously, this process matches the standard input parameter data with the interface processing strategy corresponding to the interface service type, enabling different interface services such as querying, writing, status synchronization, or combined calls to execute processing according to the adapted standard data. Therefore, this process improves the standardization of input parameter processing, the stability of interface call processing, and the reusability when different callers access the same interface service.

[0118] S7. Based on the target output parameter configuration, process the data to obtain the interface call processing result, record the call process data according to the call record rules, and output the interface call processing result.

[0119] Step S7 involves configuring the returned data from the interface call and recording the call process data according to the call recording rules. The target output parameter configuration controls the returned fields, field mapping relationships, and return format, ensuring the interface call processing results are adaptable to different caller data reception methods. The call recording rules standardize the recording of key process data during the interface call, facilitating subsequent call tracing, anomaly localization, and operation and maintenance. Through step S7, the system not only outputs interface call processing results adapted to the caller but also simultaneously retains record data related to the interface call process, improving the traceability and maintenance efficiency of the interface service operation. For example, in a fintech scenario, external cooperation platforms may require specific formats for credit limit processing results or risk identification results; step S7 can complete the return processing and record the call process according to the target output parameter configuration. In a digital healthcare scenario, different business systems may require different formats for returning patient information or examination records; step S7 can generate adapted interface call processing results based on the target output parameter configuration and record the corresponding call process data according to the call recording rules.

[0120] The data platform interface service configuration method provided in this application parses the interface service configuration request and generates a target interface service configuration instance by combining the interface configuration library, call adaptation information, and call control configuration. This transforms the interface service configuration from a fixed development approach oriented towards a single system to a configuration-oriented approach oriented towards multiple callers, multiple protocols, multiple data formats, and multiple interface versions. This method can uniformly determine routing, input parameters, output parameters, and call control configurations based on the target interface identifier, and form mutually matching target configurations according to the interface service type and call adaptation information, reducing the risk of mismatch between interface entry points, parameter rules, and return rules. Simultaneously, this method associates call permission rules, call record rules, target routing configuration, target input parameter configuration, and target output parameter configuration into the same configuration instance, forming a continuous processing chain for route matching, permission verification, parameter processing, interface call, result return, and process recording. Therefore, this method can reduce the coupling between the interface and specific business systems, improve interface reusability, cross-system adaptability, and operation and maintenance efficiency.

[0121] Please continue reading. Figure 5 , Figure 5 This is a schematic diagram of the system structure of the data platform interface service configuration device provided in the embodiments of this application, such as... Figure 5As shown, the data platform interface service configuration device 50 includes: a configuration request parsing module 51, an interface configuration determination module 52, an interface configuration adaptation module 53, a service instance generation module 54, a call request verification module 55, a call parameter processing module 56, and a call result output module 57.

[0122] The configuration request parsing module 51 is specifically used to receive interface service configuration requests, parse the interface service configuration requests, and obtain the target interface identifier, interface service type, and call adaptation information; the interface configuration determination module 52 is specifically used to determine the interface routing configuration, input parameter configuration, output parameter configuration, and call control configuration from the interface configuration library based on the target interface identifier; the interface configuration adaptation module 53 is specifically used to perform adaptation processing on the interface routing configuration, input parameter configuration, and output parameter configuration based on the interface service type and the call adaptation information to obtain the target routing configuration, target input parameter configuration, and target output parameter configuration; the service instance generation module 54 is specifically used to generate call permission rules and call record rules based on the call control configuration, and to combine the call permission rules, the call record rules, the target routing configuration, the target input parameter configuration, and the call record information. The target output parameter configuration is associated to generate a target interface service configuration instance; the call request verification module 55 is specifically used to, after receiving an interface call request for the target interface service configuration instance, perform route matching on the interface call request based on the target routing configuration, and perform permission verification on the interface call request based on the call permission rules; the call parameter processing module 56 is specifically used to, when the route matching is successful and the permission verification is passed, perform parameter processing on the input parameter data in the interface call request based on the target input parameter configuration, and execute the interface call processing corresponding to the interface call request to obtain processed data; the call result output module 57 is specifically used to, based on the target output parameter configuration, perform return processing on the processed data to obtain the interface call processing result, record the call process data according to the call record rules, and output the interface call processing result.

[0123] As an optional implementation, the configuration request parsing module 51 is further specifically used to identify the request source of the interface service configuration request to obtain request source information; extract the interface identifier field, service type field, and adaptation description field from the interface service configuration request to obtain candidate interface identifier, candidate service type, and candidate adaptation description information; perform validity verification on the candidate interface identifier according to preset interface identifier rules, and when the candidate interface identifier passes the verification, determine the candidate interface identifier as the target interface identifier; match the candidate service types according to the preset service type set, and determine the successfully matched candidate service types as the interface service types; determine the caller type, calling protocol, data format information, and interface version information based on the request source information and candidate adaptation description information; and generate calling adaptation information based on the caller type, calling protocol, data format information, and interface version information.

[0124] As an optional implementation, the interface configuration determination module 52 is further configured to query the interface configuration index table in the interface configuration library according to the target interface identifier to obtain candidate interface configuration records associated with the target interface identifier; perform configuration status verification on the candidate interface configuration records to obtain valid interface configuration records; determine the target interface configuration version from the valid interface configuration records according to the interface service type and call adaptation information; read the routing configuration record, input parameter configuration record, output parameter configuration record, and call control configuration record associated with the target interface identifier from the interface configuration library according to the target interface configuration version; perform association consistency verification on the routing configuration record, input parameter configuration record, output parameter configuration record, and call control configuration record; when the association consistency verification passes, determine the routing configuration record as the interface routing configuration, determine the input parameter configuration record as the input parameter configuration, determine the output parameter configuration record as the output parameter configuration, and determine the call control configuration record as the call control configuration.

[0125] As an optional implementation, the interface configuration adaptation module 53 is further specifically used to determine, based on the interface service type, a routing adaptation strategy, an input parameter adaptation strategy, and an output parameter adaptation strategy; based on the calling protocol and interface version information in the calling adaptation information, adapt the access path, request method, and version identifier in the interface routing configuration according to the routing adaptation strategy to obtain the target routing configuration; based on the caller type and data format information in the calling adaptation information, adapt the parameter item enable status, parameter source, and parameter format in the input parameter configuration according to the input parameter adaptation strategy to obtain the target input parameter configuration; based on the data format information and interface version information in the calling adaptation information, adapt the return field, field mapping relationship, and return format in the output parameter configuration according to the output parameter adaptation strategy to obtain the target output parameter configuration; perform adaptation consistency verification on the target routing configuration, target input parameter configuration, and target output parameter configuration; when the adaptation consistency verification passes, determine that the target routing configuration, target input parameter configuration, and target output parameter configuration are used to generate a target interface service configuration instance.

[0126] As an optional implementation, the service instance generation module 54 is further configured to extract permission control data and record control data corresponding to the target interface identifier from the call control configuration; generate call permission rules for verifying the permissions of the interface call request based on the permission control data, the interface service type, and the call adaptation information; generate call record rules for recording the call process data of the interface call request based on the record control data; configure the call permission rules as the pre-verification rules corresponding to the target route configuration; configure the target input parameter configuration and the target output parameter configuration as the parameter processing rules and return processing rules corresponding to the target route configuration, respectively; configure the call record rules as the process record rules corresponding to the interface call processing; and generate a target interface service configuration instance.

[0127] As an optional implementation, the call request verification module 55 is further configured to extract request routing information and caller verification information from the interface call request; match the request routing information with the target routing configuration to obtain a routing matching result; when the routing matching result indicates successful routing, invoke the pre-verification rules corresponding to the target routing configuration; based on the pre-verification rules, perform permission verification on the caller verification information, interface service type, and call adaptation information; when the permission verification passes, transfer the interface call request to the parameter processing flow corresponding to the target input parameter configuration.

[0128] As an optional implementation, the call parameter processing module 56 is further specifically used to: determine the input parameter data to be processed corresponding to the enabled parameter item from the interface call request according to the target input parameter configuration; perform field mapping on the input parameter data to be processed according to the parameter mapping relationship in the target input parameter configuration to obtain mapped input parameter data; perform format conversion and validity verification on the mapped input parameter data according to the parameter format rules and parameter verification rules in the target input parameter configuration to obtain standard input parameter data; when the standard input parameter data passes the verification, determine the interface processing strategy corresponding to the standard input parameter data according to the interface service type; run the interface processing strategy, and perform interface call processing corresponding to the interface call request based on the standard input parameter data to obtain processed data.

[0129] It should be noted that the aforementioned data platform interface service configuration device can execute the data platform interface service configuration method provided in the embodiments of this application, and has the corresponding functional modules and beneficial effects of the method. Technical details not described in detail in the embodiments of the data platform interface service configuration device can be found in the data platform interface service configuration method provided in the embodiments of this application.

[0130] Figure 6 This is a schematic diagram of the hardware structure of the electronic device for configuring the execution data platform interface service provided in the embodiments of this application, as shown below. Figure 6 As shown, the electronic device 600 includes: One or more processors 610 and memory 620, Figure 6 Take the 610 processor as an example.

[0131] The processor 610 and the memory 620 can be connected via a bus or other means. Figure 6 Taking the example of a connection between China and Israel via a bus.

[0132] The memory 620, as a non-volatile computer-readable storage medium, can be used to store non-volatile software programs, non-volatile computer-executable programs, and modules, such as the program instructions / modules corresponding to the data platform interface service configuration method in the embodiments of this application. The processor 610 executes various functional applications and data processing of the server by running the non-volatile software programs, instructions, and modules stored in the memory 620, thereby implementing the data platform interface service configuration method of the above-described method embodiments.

[0133] The memory 620 may include a program storage area and a data storage area. The program storage area may store the operating system and applications required for at least one function; the data storage area may store data created based on the use of the data platform interface service configuration device. Furthermore, the memory 620 may include high-speed random access memory and may also include non-volatile memory, such as at least one disk storage device, flash memory device, or other non-volatile solid-state storage device. In some embodiments, the memory 620 may optionally include memory remotely located relative to the processor 610, and these remote memories can be connected to the data platform interface service configuration device via a network. Examples of such networks include, but are not limited to, the Internet, corporate intranets, local area networks, mobile communication networks, and combinations thereof.

[0134] The one or more modules are stored in the memory 620. When executed by the one or more processors 610, they execute the data platform interface service configuration method in any of the above method embodiments, for example, executing the above-described... Figure 2 Method steps S1 to S7, Figure 3 Method steps S31 to S36, Figure 4 Steps S41 to S46 in the method are implemented. Figure 5 The functions of modules 51-57 in the document.

[0135] The above-described product can perform the methods provided in the embodiments of this application, and has the corresponding functional modules and beneficial effects for performing the methods. Technical details not described in detail in this embodiment can be found in the methods provided in the embodiments of this application.

[0136] This application provides a non-volatile computer-readable storage medium storing computer-executable instructions that are executed by one or more processors, for example... Figure 6 One of the processors 610 can enable the one or more processors to execute the data platform interface service configuration method in any of the above method embodiments, for example, to execute the above-described... Figure 2 Method steps S1 to S7, Figure 3 Method steps S31 to S36, Figure 4 Steps S41 to S46 in the method are implemented. Figure 5 The functions of modules 51-57 in the document.

[0137] This application provides a computer program product, which includes a computer program stored on a non-volatile computer-readable storage medium. The computer program includes program instructions, which, when executed by an electronic device, enable the electronic device to perform the data platform interface service configuration method described in any of the above method embodiments, for example, to perform the above-described... Figure 2 Method steps S1 to S7, Figure 3 Method steps S31 to S36, Figure 4 Steps S41 to S46 in the method are implemented. Figure 5 The functions of modules 51-57 in the document.

[0138] The device embodiments described above are merely illustrative. The units described as separate components may or may not be physically separate. The components shown as units may or may not be physical units; that is, they may be located in one place or distributed across multiple network units. Some or all of the modules can be selected to achieve the purpose of this embodiment according to actual needs.

[0139] Through the above description of the embodiments, those skilled in the art can clearly understand that each embodiment can be implemented using software and a general-purpose hardware platform, or of course, using hardware. Those skilled in the art will understand that all or part of the processes in the above embodiments can be implemented by a computer program instructing related hardware. The program can be stored in a computer-readable storage medium, and when executed, it can include the processes of the embodiments of the above methods. The storage medium can be a magnetic disk, optical disk, read-only memory (ROM), or random access memory (RAM), etc.

[0140] It should be noted that any AI models, software tools, or components not belonging to this company appearing in the embodiments of this application are merely illustrative examples and do not represent actual use. All user personal information involved in the embodiments of this application has been authorized (with the knowledge and consent) by the relevant parties or has been fully authorized by all parties, and the executing entity may obtain it through various legal and compliant means. The collection, storage, use, processing, transmission, provision, and disclosure of the information, data, and signals involved all comply with relevant laws and regulations and do not violate public order and good morals.

[0141] Finally, it should be noted that the above embodiments are only used to illustrate the technical solutions of this application, and not to limit them; under the concept of this application, the technical features of the above embodiments or different embodiments can also be combined, the steps can be implemented in any order, and there are many other variations of different aspects of this application as described above, which are not provided in detail for the sake of brevity; although this application has been described in detail with reference to the foregoing embodiments, those skilled in the art should understand that they can still modify the technical solutions described in the foregoing embodiments, or make equivalent substitutions for some of the technical features; and these modifications or substitutions do not cause the essence of the corresponding technical solutions to deviate from the scope of the technical solutions of the embodiments of this application.

Claims

1. A method for configuring a data platform interface service, characterized in that, include: Receive an interface service configuration request, parse the interface service configuration request, and obtain the target interface identifier, interface service type, and call adaptation information; Based on the target interface identifier, determine the interface routing configuration, input parameter configuration, output parameter configuration, and call control configuration from the interface configuration library; Based on the interface service type and the call adaptation information, the interface routing configuration, the input parameter configuration and the output parameter configuration are adapted to obtain the target routing configuration, the target input parameter configuration and the target output parameter configuration. Based on the call control configuration, call permission rules and call record rules are generated, and the call permission rules, the call record rules, the target route configuration, the target input parameter configuration, and the target output parameter configuration are associated to generate a target interface service configuration instance; Upon receiving an interface call request for the target interface service configuration instance, the system performs route matching on the interface call request based on the target routing configuration and performs permission verification on the interface call request based on the call permission rules. When the route is successfully matched and the permission verification is passed, the input parameter data in the interface call request is processed based on the target input parameter configuration, and the interface call processing corresponding to the interface call request is executed to obtain the processed data. Based on the target output parameter configuration, the processing data is returned to obtain the interface call processing result. The call process data is recorded according to the call record rules, and the interface call processing result is output.

2. The data platform interface service configuration method according to claim 1, characterized in that, The received interface service configuration request is parsed to obtain the target interface identifier, interface service type, and invocation adaptation information, including: The request source of the interface service configuration request is identified to obtain the request source information; Extract the interface identifier field, service type field, and adaptation description field from the interface service configuration request to obtain candidate interface identifier, candidate service type, and candidate adaptation description information. The candidate interface identifier is validated according to the preset interface identifier rules. When the candidate interface identifier passes the validation, the candidate interface identifier is determined as the target interface identifier. The candidate service types are matched according to a preset set of service types, and the successfully matched candidate service types are determined as the interface service types. Based on the request source information and the candidate adaptation description information, the caller type, calling protocol, data format information and interface version information are determined; The call adaptation information is generated based on the caller type, the call protocol, the data format information, and the interface version information.

3. The data platform interface service configuration method according to claim 1, characterized in that, The step of determining the interface routing configuration, input parameter configuration, output parameter configuration, and call control configuration from the interface configuration library based on the target interface identifier includes: Based on the target interface identifier, query the interface configuration index table in the interface configuration library to obtain the candidate interface configuration record associated with the target interface identifier; The configuration status of the candidate interface configuration records is verified to obtain the valid interface configuration records; Based on the interface service type and the call adaptation information, determine the target interface configuration version from the valid interface configuration record; Based on the target interface configuration version, read the routing configuration record, input parameter configuration record, output parameter configuration record, and call control configuration record associated with the target interface identifier from the interface configuration library; Perform an association consistency check on the routing configuration record, the input parameter configuration record, the output parameter configuration record, and the call control configuration record; When the association consistency verification passes, the routing configuration record is determined as the interface routing configuration, the input parameter configuration record is determined as the input parameter configuration, the output parameter configuration record is determined as the output parameter configuration, and the call control configuration record is determined as the call control configuration.

4. The data platform interface service configuration method according to claim 1, characterized in that, The step of adapting the interface routing configuration, input parameter configuration, and output parameter configuration according to the interface service type and the call adaptation information to obtain the target routing configuration, target input parameter configuration, and target output parameter configuration includes: Based on the interface service type, determine the routing adaptation strategy, input parameter adaptation strategy, and output parameter adaptation strategy corresponding to the interface service type; Based on the calling protocol and interface version information in the calling adaptation information, the access path, request method and version identifier in the interface routing configuration are adapted according to the routing adaptation strategy to obtain the target routing configuration; Based on the caller type and data format information in the call adaptation information, the parameter item activation status, parameter source and parameter format in the input parameter configuration are adapted according to the input parameter adaptation strategy to obtain the target input parameter configuration; Based on the data format information and interface version information in the call adaptation information, the return fields, field mapping relationships and return formats in the output parameter configuration are adapted according to the output parameter adaptation strategy to obtain the target output parameter configuration; Perform an adaptation consistency check on the target route configuration, the target input parameter configuration, and the target output parameter configuration; When the adaptation consistency verification passes, the target routing configuration, the target input parameter configuration, and the target output parameter configuration are determined to be used to generate a target interface service configuration instance.

5. The data platform interface service configuration method according to claim 1, characterized in that, The step involves generating call permission rules and call record rules based on the call control configuration, and associating the call permission rules, the call record rules, the target route configuration, the target input parameter configuration, and the target output parameter configuration to generate a target interface service configuration instance, including: Extract the permission control data and record control data corresponding to the target interface identifier from the call control configuration; Based on the permission control data, the interface service type, and the call adaptation information, call permission rules are generated for verifying the permissions of interface call requests; Based on the record control data, generate call record rules for recording the call process data of interface call requests; Configure the invocation permission rule as the pre-verification rule corresponding to the target route configuration; Configure the target input parameter configuration and the target output parameter configuration as the parameter processing rules and return processing rules corresponding to the target routing configuration, respectively. Configure the call record rules as the process record rules corresponding to the interface call processing, and generate the target interface service configuration instance.

6. The data platform interface service configuration method according to claim 5, characterized in that, Upon receiving an interface call request for the target interface service configuration instance, the process involves performing route matching on the interface call request based on the target routing configuration and performing permission verification on the interface call request based on the call permission rules, including: Extract request routing information and caller verification information from the interface call request; The requested routing information is matched with the target routing configuration to obtain the routing matching result; When the route matching result indicates that the route matching is successful, the pre-verification rule corresponding to the target route configuration is invoked. Based on the aforementioned pre-verification rules, permission verification is performed on the caller verification information, the interface service type, and the call adaptation information. When the permission verification passes, the interface call request will be transferred to the parameter processing flow corresponding to the target input parameter configuration.

7. The data platform interface service configuration method according to claim 1, characterized in that, When the route is successfully matched and the permission verification passes, the parameter data in the interface call request is processed based on the target input parameter configuration, and the interface call processing corresponding to the interface call request is executed to obtain processed data, including: Based on the target input parameter configuration, determine the input parameter data to be processed corresponding to the enabled parameter item from the interface call request; Based on the parameter mapping relationship in the target input parameter configuration, the field mapping of the input parameter data to be processed is performed to obtain the mapped input parameter data; Based on the parameter format rules and parameter validation rules in the target input parameter configuration, the mapped input parameter data is format converted and validity validated to obtain standard input parameter data; When the standard input parameter data passes the verification, the interface processing strategy corresponding to the standard input parameter data is determined according to the interface service type. The interface processing strategy is executed, and the interface call processing corresponding to the interface call request is performed based on the standard input parameter data to obtain the processing data.

8. A data platform interface service configuration device, characterized in that, include: The configuration request parsing module is used to receive interface service configuration requests, parse the interface service configuration requests, and obtain the target interface identifier, interface service type, and call adaptation information. The interface configuration determination module is used to determine the interface routing configuration, input parameter configuration, output parameter configuration and call control configuration from the interface configuration library based on the target interface identifier. The interface configuration adaptation module is used to adapt the interface routing configuration, the input parameter configuration, and the output parameter configuration according to the interface service type and the call adaptation information to obtain the target routing configuration, the target input parameter configuration, and the target output parameter configuration. The service instance generation module is used to generate call permission rules and call record rules according to the call control configuration, and associate the call permission rules, the call record rules, the target route configuration, the target input parameter configuration and the target output parameter configuration to generate a target interface service configuration instance; The request verification module is used to perform route matching on the interface call request based on the target routing configuration and to perform permission verification on the interface call request based on the call permission rules after receiving the interface call request for the target interface service configuration instance. The parameter processing module is invoked to process the input parameter data in the interface call request based on the target input parameter configuration when the route matching is successful and the permission verification is passed, and to execute the interface call processing corresponding to the interface call request to obtain the processed data. The call result output module is used to return the processing data based on the target output parameter configuration, obtain the interface call processing result, record the call process data according to the call record rules, and output the interface call processing result.

9. An electronic device, characterized in that, include: At least one processor; as well as, A memory communicatively connected to the at least one processor; wherein, The memory stores instructions that can be executed by the at least one processor, which, when executed by the at least one processor, enables the at least one processor to perform the data platform interface service configuration method according to any one of claims 1-7.

10. A non-volatile computer-readable storage medium, characterized in that, The non-volatile computer-readable storage medium stores computer-executable instructions, which, when executed by an electronic device, cause the electronic device to perform the data platform interface service configuration method according to any one of claims 1-7.

Images