An API real-time acquisition method based on SPI extensible mechanism

Abstract

The application discloses an API real-time collection method based on an SPI extensible mechanism, provides a solution with good quasi-real-time performance and data consistency for collecting API interfaces of a unified platform, and defines SPI interfaces and extension points in a process uniformly by referring to the mechanism of Java SPI, and then the SPI interfaces are implemented by providers of various interfaces. In the whole access process, data is only retained on the providers of the interfaces, and there is no problem of data redundancy. In subsequent scene display logic, the SPI interfaces are called as needed, and are uniformly returned to the front end for display, so that better data real-time performance and data consistency are provided.

Description

Technical Field

[0001] This invention relates to a data acquisition method, and more specifically to a real-time data acquisition method for APIs based on the SPI extensible mechanism. Background Technology

[0002] The Capability Center serves as a centralized platform for managing and providing API interfaces during enterprise digitalization. It offers a unified API catalog and documentation, enabling developers to more easily discover, understand, and use APIs. Developers no longer need to repeatedly write and implement the same functionality; instead, they can directly use existing APIs, saving development time and effort. Figure 1 As shown:

[0003] The developers provide Interface 1.0 in the Permission Center. Simultaneously, upon application startup, the system directly calls the registration interface provided by the Capability Center, writing the complete interface definition into the Capability Center's database. Subsequently, when third-party users view interface information, the Capability Center directly returns the data from the database for display. The interface update strategy is similar.

[0004] In the actual R&D process, we found many problems with the collected APIs, such as missing interfaces and untimely updates. Users were unable to fully utilize the new functions or adapt to the changing needs, which led to delays and confusion in the development progress.

[0005] The root cause of the above problem is that the interface definition data is synchronized (redundantly) to the application in the capability center to ensure consistent display. When the interface definition changes, both stored data need to be modified simultaneously to guarantee consistency. However, because the physical media of the two storage locations are often cross-process and cross-machine, simultaneous modifications may fail due to human error, update failures, network fluctuations, etc., leading to inconsistencies in the interface. Figure 2 As shown:

[0006] The enterprise platform's permission module version 1.0 provides a query interface based on user ID. Developers can use this interface to query detailed user information by passing in the user's ID.

[0007] After the API was released, external third-party applications relied on it to implement user login and queries. These applications were integrated with the enterprise platform's API version 1.0 at the time of release.

[0008] In subsequent product iterations, the permissions module was updated to version 2.0, which changed the above interface to a query interface based on username.

[0009] However, after the version was released, network jitter caused the synchronous update of the interface definitions and documentation in the capability center to fail during the application startup process.

[0010] At this point, the third-party application is still obtaining the 1.0 version of the interface definition from the capability center, but it is actually running version 2.0. This causes errors in both existing and incremental business logic of subsequent applications, preventing the business from continuing. Summary of the Invention

[0011] In view of the shortcomings of the existing technology, the purpose of this invention is to provide an API real-time acquisition method based on the SPI extensible mechanism that provides a more accurate and real-time interface definition and quickly conveys updated and changed information.

[0012] To achieve the above objectives, the present invention provides the following technical solution: a real-time acquisition method for API based on the SPI scalable mechanism, comprising the following steps:

[0013] Step 1: The developer's terminal sends a message to the permission center to add a query interface 1.0 based on user ID; Step 2: After receiving the message to add a query interface 1.0 based on user ID, the permission center persists the interface 1.0 and then sends a message to the developer's terminal to indicate that the addition was successful.

[0014] Step 3: Use the terminal to send an interface viewing message to the capability center. After receiving the message, the capability center sends an interface query message to the permission center. After receiving the interface query message, the permission center performs the query steps and then returns the interface 1.0 message to the capability center, which then feeds back to the user terminal.

[0015] Step 4: The R&D personnel send a message to the permission center to update the query interface 2.0 based on user ID.

[0016] Step 5: After receiving the message that a new query interface 2.0 based on user ID has been added, the permission center persists the interface 2.0 and then sends a success message to the developer's terminal.

[0017] Step Six: The terminal sends an interface viewing message to the Capability Center. Upon receiving the message, the Capability Center sends an interface query message to the Permission Center. Upon receiving the interface query message, the Permission Center performs the query and then returns an Interface 2.0 message to the Capability Center, which then relays the message back to the user terminal. As a further improvement of this invention, the query steps in Steps Three and Six specifically include:

[0018] Step 31: After the permission center receives the interface query message, it performs parameter validity verification, which is a process of verifying and checking the input parameters, including data type checking and null value checking.

[0019] Step 32: Perform business validation to determine whether the parameters meet the business rules;

[0020] Step 33: Assemble the query parameters, converting external parameters into objects that the internal system can recognize;

[0021] Steps three and four involve executing the query logic by calling the underlying function with the passed-in transformed parameters.

[0022] Step 35: Adapt the query results, obtain the data returned from the underlying layer, and adapt it to the requirements of this page.

[0023] Step 36: Return the processed result value to the Capability Center.

[0024] As a further improvement of the present invention, the specific steps for executing the query logic in steps three and four are to define the node as an extensible node and define the SPI interface.

[0025] As a further improvement of the present invention, the specific steps of defining the node as an extensible node and defining the SPI interface are as follows: obtain the current group and sub-group information, including API information, through the ApiInfoPi service of the public interface; then query the API details according to the unique API identifier through the category with the ApiDTO page; after the definition is completed, encapsulate the SPI interface into the SDK and provide it to each business party that needs to access it; after each business party introduces the SDK, implements the detail method of the corresponding SPI interface; and at the beginning of application startup, uses the terminal to register its application tag and call parameter information to the capability center.

[0026] As a further improvement of the present invention, the parameters attached to the information registration request include service name, service domain and service type, wherein the service name is Model API, the service domain is isc-tddm-service:38800 and the service type is tddm.

[0027] The beneficial effect of this invention is that, through the settings in steps one through six, all operations—adding, updating, and reading—ultimately reside in the storage of the permission center. This means that within the entire system, only one copy of the interface definition is retained. There is no data redundancy, and therefore no data consistency issues. Attached Figure Description

[0028] Figure 1 This is a schematic diagram of the API acquisition process in existing technologies;

[0029] Figure 2 This is a schematic diagram of an existing process that cannot be transferred.

[0030] Figure 3 This is a flowchart illustrating the data acquisition method of the present invention;

[0031] Figure 4 A schematic diagram of the internal logic of the API query interface;

[0032] Figure 5 This is a diagram illustrating how each business unit implements the corresponding SPI interface detail method after introducing this SDK;

[0033] Figure 6 This is a diagram illustrating the registration process performed by the user terminal at the initial launch of the application.

[0034] Figure 7 This is a flowchart illustrating the query call process. Detailed Implementation

[0035] The present invention will now be described in further detail with reference to the embodiments shown in the accompanying drawings.

[0036] Terminology Explanation:

[0037] API (Application Programming Interface)

[0038] An API is a set of rules and protocols that define interactions between software components or systems. APIs allow different software applications to communicate and exchange data to achieve specific functions or services.

[0039] Capability Center

[0040] A centralized platform or service for managing and providing API interfaces. It provides a centralized access point for developers, partners, or third-party applications so they can find, invoke, and use different APIs. JavaSPI (Service Provider Interface)

[0041] Java's Service Provider Discovery (SPI) mechanism is a built-in service discovery mechanism in the JDK. It enables framework extensions and component replacements, primarily used by framework developers. For example, the `java.sql.Driver` interface can be implemented differently by different vendors; MySQL and PostgreSQL each offer different implementations. Java's SPI mechanism can find service implementations for a given interface. The core idea of ​​Java's SPI mechanism is to move assembly control outside the program. This mechanism is particularly important in modular design, and its core principle is decoupling.

[0042] Reference Figures 3 to 6 As shown in this embodiment, a real-time API acquisition method based on the SPI scalable mechanism is characterized by the following steps:

[0043] Step 1: The developer's terminal sends a message to the permission center to add a query interface 1.0 based on user ID; Step 2: After receiving the message to add a query interface 1.0 based on user ID, the permission center persists the interface 1.0 and then sends a message to the developer's terminal to indicate that the addition was successful.

[0044] Step 3: Use the terminal to send an interface viewing message to the capability center. After receiving the message, the capability center sends an interface query message to the permission center. After receiving the interface query message, the permission center performs the query steps and then returns the interface 1.0 message to the capability center, which then feeds back to the user terminal.

[0045] Step 4: The R&D personnel send a message to the permission center to update the query interface 2.0 based on user ID.

[0046] Step 5: After receiving the message that a new query interface 2.0 based on user ID has been added, the permission center persists the interface 2.0 and then sends a success message to the developer's terminal.

[0047] Step Six: The terminal sends an interface view message to the Capability Center. Upon receiving the message, the Capability Center sends an interface query message to the Permission Center. The Permission Center, upon receiving the query message, performs the query and then returns an Interface 2.0 message to the Capability Center. The Capability Center then relays this message back to the user terminal. Through the settings in steps One through Six, the addition, updating, and reading of operations can be achieved, ultimately all ending up in the Permission Center's storage. This means that in the entire system, only one copy of the interface definition is retained. There is no data redundancy, thus eliminating data consistency issues and providing more accurate and real-time interface definitions, quickly conveying updated and changed information.

[0048] The specific implementation of the above method is divided into two parts: SPI design and operation mechanism.

[0049] The following is a detailed explanation:

[0050] SPI Design

[0051] The definition of the SPI interface needs to be based on the analysis of the entire business process, while also taking into account the current access status of various business implementation parties, and to achieve a unified abstraction.

[0052] In the implementation of the solution, the entire query process is first decomposed, and then the parts that need to be extended in each process node are analyzed.

[0053] After identifying the process nodes, the next step is to abstract each node and provide a standard SPI interface that can meet the needs of all access parties and also fully display the interface information to the user.

[0054] Here, we take "Query API Details" as an example: Figure 4 As shown

[0055] The internal logic of the entire "Query API Details" interface is broken down as follows:

[0056] 1) Parameter validity validation: The process of validating and checking input parameters, including data type checking, null value checking, etc.

[0057] 2) Business validation: Parameters must meet specific business rules.

[0058] 3) Query parameter assembly: Converting external parameters into objects that the internal system can recognize.

[0059] 4) Execute query logic: Pass in the transformed parameters, call the underlying function, and execute the query logic.

[0060] 5) Query result adaptation: Obtain the data returned from the underlying layer and adapt it to the specific requirements of this page.

[0061] 6) Return the result value: Return the processed result.

[0062] Define the "Execute Query Logic" node as an extensible node, and also define the SPI interface: public interface ApiInfoSpiService{

[0063] / **

[0064] * Retrieve information about the current group and its subgroups, including API information.

[0065] *@return

[0066] /

[0067] CategoryWithApiDTO page();

[0068] / **

[0069] *Query API details based on API unique identifier

[0070] *@param code

[0071] *@return

[0072] /

[0073] ApiInfoDetailDTO detail(String code);

[0074] }

[0075] After the SPI interface is defined, it is encapsulated into the SDK and provided to all business units that need to access it. After importing the SDK, each business unit implements the corresponding SPI interface's detail method, such as... Figure 5 As shown.

[0076] At the beginning of application startup, register your application tags and call parameters with the capability center, such as... Figure 6 As shown. The parameters included in the information registration request are configured as follows:

[0077] #Configuration of the docking capability center

[0078] Isc-capc:

[0079] serviceName: Model API

[0080] serviceDomain:isc-tddm-service:38800

[0081] serviceType:tddm

[0082] The above parameters are used by the Capability Center to identify which applications have registered, and the interface path and configuration for calling SPI.

[0083] Operating mechanism

[0084] When upstream interfaces call the capability center's openAPI or display information on a page, the capability center identifies which applications implement the SPI interface based on the tags registered by the applications. Simultaneously, it initiates the actual call based on the configuration registered by the corresponding application, retrieves the result, and returns it to the upstream business, such as... Figure 7 As shown.

[0085] The above description is merely a preferred embodiment of the present invention. The scope of protection of the present invention is not limited to the above embodiments. All technical solutions falling within the scope of the present invention's concept are within the scope of protection of the present invention. It should be noted that for those skilled in the art, any improvements and modifications made without departing from the principles of the present invention should also be considered within the scope of protection of the present invention.

Claims

1. A real-time acquisition method for API based on the SPI extensible mechanism, characterized in that: Includes the following steps: Step 1: The R&D personnel send a message to the permission center from their terminal indicating the addition of a new query interface 1.0 based on user ID; Step 2: After receiving the message that a new query interface 1.0 based on user ID has been added, the permission center persists interface 1.0 and then sends a success message to the developer's terminal. Step 3: Use the terminal to send an interface viewing message to the capability center. After receiving the message, the capability center sends an interface query message to the permission center. After receiving the interface query message, the permission center performs the query steps and then returns the interface 1.0 message to the capability center, which then feeds back to the user terminal. Step 4: The R&D personnel send a message to the permission center to update the query interface 2.0 based on user ID. Step 5: After receiving the message that a new query interface 2.0 based on user ID has been added, the permission center persists interface 2.0 and then sends a success message to the developer's terminal. Step 6: Use the terminal to send an interface viewing message to the capability center. After receiving the message, the capability center sends an interface query message to the permission center. After receiving the interface query message, the permission center performs the query steps and then returns an interface 2.0 message to the capability center, which then feeds back to the user terminal. The query steps in steps three and six specifically include: Step 31: After the permission center receives the interface query message, it performs parameter validity verification, which is a process of verifying and checking the input parameters, including data type checking and null value checking. Step 32: Perform business validation to determine whether the parameters meet the business rules; Step 33: Assemble the query parameters, converting external parameters into objects that the internal system can recognize; Steps three and four involve executing the query logic. This involves passing in the transformed parameters, calling the underlying function, and executing the query logic. Specifically, this execution involves defining the node as an extensible node and defining the SPI interface. The steps for defining the node as an extensible node and defining the SPI interface are as follows: Obtain the current group and sub-group information, including API information, through the ApiInfoPi service of the public interface; then query the API details based on the unique API identifier using the category with the ApiDTO page; and after definition, encapsulate the SPI interface into the SDK and provide it to all business units that need to access it. After introducing the SDK, each business unit implements the corresponding SPI interface's detail method and registers its application tag and call parameter information with the capability center using the terminal at the beginning of application startup. Step 35: Adapt the query results, obtain the data returned from the underlying layer, and adapt it to the requirements of this page. Step 36: Return the processed result value to the Capability Center.

2. The API real-time acquisition method based on the SPI scalable mechanism according to claim 1, characterized in that: The information registration request includes parameters such as service name, service domain, and service type. The service name is Model API, the service domain is isc-tddm-service:38800, and the service type is tddm.

Images