CN116450103A

CN116450103A - Interface registration and execution method, device and management system

Info

Publication number: CN116450103A
Application number: CN202210010668.9A
Authority: CN
Inventors: 吕望; 王艳花
Original assignee: Beijing Jingdong Century Trading Co Ltd; Beijing Wodong Tianjun Information Technology Co Ltd
Current assignee: Beijing Jingdong Century Trading Co Ltd; Beijing Wodong Tianjun Information Technology Co Ltd
Priority date: 2022-01-05
Filing date: 2022-01-05
Publication date: 2023-07-18

Abstract

The invention discloses an interface registration and execution method, an interface registration and execution device and a management system, and relates to the technical field of computers. The interface registration method comprises the following steps: analyzing the interface configuration file to obtain interface configuration information; loading the implementation class of the interface according to the interface configuration information, and creating an interface executor based on the implementation class of the interface; and determining an interface unique identifier, and correspondingly storing the interface unique identifier and the interface executor to finish the registration of the interface. The method realizes the rapid and efficient interface registration through the steps, greatly simplifies the complexity of the interface registration or the interface release, reduces the technical threshold of the interface research and development, and improves the research and development efficiency of the interface.

Description

Interface registration and execution method, device and management system

Technical Field

The present invention relates to the field of computer technologies, and in particular, to an interface registration and execution method, an apparatus, and a management system.

Background

The most mainstream way of sharing the system development results is to issue the research results into services, and other system development results can multiplex the functions by calling the services. This is also the core idea of Software-as-a-Service (SAAS) and platform-as-Service (PAAS, platform as a Service). The nature of these services is that of interfaces that can satisfy individual functions. The most central thing that many times system research and development did is to develop a single functional interface for other research and development personnel to call, which is the mainstream research and development mode of many internet enterprises.

Currently, functional interfaces are often developed for projects. For example, to develop a new functional interface, it is often necessary to create a project or create a branch on an existing project, develop corresponding code, then compile, package, deploy, and release the entire project into a clustered environment. What is called interface development is often followed by the development of individual projects.

In the process of implementing the present invention, the inventor of the present invention found that the project-based interface development management method has the following problems:

first, develop, manage, maintain the interface based on the way of the project, make the research and development of the interface become research and development of the project, have increased work load and technological complexity of research and development, have increased the time cost of research and development and debugging of the interface. The online of the project often needs operations such as compiling, packing, deploying, and the like, so the management and maintenance of the interface based on the project often needs to do the matters, one interface is slightly changed, or a plurality of interfaces are newly added, and the whole project needs to be recompiled, packed and deployed. If this project is relatively large, it may take a long time to compile and deploy, and each compilation project consumes significant system resources. It sometimes takes a long time to develop code that submits a section of interface to see the effect on-line. When some interface research and development cannot be debugged locally, a long time is required to be released on line, and when some problems are encountered, the time for debugging the interface is greatly prolonged.

Secondly, the coupling degree between the interfaces is large, and new problems are easily introduced by the new addition and modification of the interfaces. Furthermore, many interfaces are added and modified, which involves compiling and packaging items, and sometimes may be executed successfully locally, while code on the line is compiled, because the local environment and the line cannot be guaranteed to be completely consistent. Sometimes the technical framework used by some new interfaces is not compatible with the old interfaces, so it is very difficult to release them together in one project.

In summary, the interface management and maintenance mode based on the project changes the research, development, management and maintenance of the interface into the research, development, management and maintenance flow of the project, the mode complicates the original simple matters, and one thing flow becomes complex, so that various problems may occur in each flow and link, which essentially corresponds to the improvement of research and development cost and the reduction of service reliability.

Disclosure of Invention

In view of this, the present invention provides an interface registration and execution method, device and management system, which reduces the technological threshold for interface research and development, improves the efficiency of interface research and development, and reduces the complexity of interface management.

To achieve the above object, according to a first aspect of the present invention, there is provided an interface registration method.

The interface registration method of the invention comprises the following steps: analyzing the interface configuration file to obtain interface configuration information; loading the implementation class of the interface according to the interface configuration information, and creating an interface executor based on the implementation class of the interface; and determining an interface unique identifier, and correspondingly storing the interface unique identifier and the interface executor to finish the registration of the interface.

Optionally, the method further comprises: creating a custom class loader to execute the step of loading the implementation class of the interface according to the interface configuration information through the custom class loader.

Optionally, the interface configuration file includes: a main library file configuration item, which is used for configuring a main library file used by the current interface file; a reference interface file configuration item for configuring other interface files referenced by the current interface file; and an executable file configuration item for configuring an executable file of the current interface file; the interface configuration file further includes: the interface realization class packet path configuration item is used for configuring a packet file path where the interface realization class is located under the condition that the interface is defined in an annotating mode; and/or an interface realization class basic information configuration item, which is used for configuring basic information of the interface realization class under the condition that the interface is defined by a configuration mode; wherein, the basic information of the interface implementation class comprises: the class name of the interface implementation class, and the method name used.

Optionally, the custom class loader includes: the first class loader is used for loading the package files under all paths configured under the configuration items of the main library file; the second class loader is inherited to the first class loader and is used for loading the package files under all paths configured under the reference interface file configuration items; and the third class loader is inherited to the second class loader and is used for loading the package files under all paths configured under the executable file configuration items.

Optionally, the implementation class of loading the interface according to the interface configuration information includes: invoking a third class loader to load the package files under all paths configured under the executable file configuration items; under the condition that the interface realization class packet path configuration item is not empty, scanning all class files under a packet file path configured by the interface realization class packet path configuration item to load the class files with notes; and under the condition that the interface implementation class basic information configuration item is not empty, loading the implementation class of the interface according to the basic information of the interface implementation class designated by the interface implementation class basic information configuration item.

Optionally, the interface is uniquely identified as a request route of the interface; the storing the unique interface identifier and the interface executor correspondingly comprises the following steps: adding the request route of the interface to a route tree; the route corresponding to the request route in the route tree comprises one or more nodes, and each node is used for storing the route parameters of the corresponding level contained in the request route; and storing corresponding interface executors at the final nodes of the paths corresponding to the request routes of the interfaces.

To achieve the above object, according to a second aspect of the present invention, there is provided an interface execution method.

The interface execution method of the invention comprises the following steps: responding to an interface call request of a user side, and analyzing request parameters in the interface call request; the request parameters include: an interface unique identifier; inquiring registered interface information to obtain an interface executor corresponding to the unique interface identifier; and calling the interface executor and sending an execution result of the interface executor to the user side.

Optionally, the interface is uniquely identified as a request route of the interface; the registered interface information is stored in the form of a routing tree; the querying the registered interface information to obtain the interface executor corresponding to the unique interface identifier comprises: splitting the request route of the interface into a plurality of levels of route parameters to obtain an array formed by the plurality of levels of route parameters; performing path retrieval in the routing tree according to the array; and under the condition that the path corresponding to the request route is retrieved, acquiring an interface executor corresponding to the request type of the interface call request from a final node of the path.

Optionally, the method further comprises: and searching an interface file corresponding to the request route from an interface file storage path and returning a query result to the user side under the condition that a path corresponding to the request route is not retrieved from the route tree or an interface executor corresponding to the request type of the interface call request is not obtained from the final-stage node of the path corresponding to the request route.

To achieve the above object, according to a third aspect of the present invention, there is provided an interface registration apparatus.

The interface registration device of the present invention includes: the analysis module is used for analyzing the interface configuration file to obtain interface configuration information; the loading module is used for loading the implementation class of the interface according to the interface configuration information and creating an interface executor based on the implementation class of the interface; and the registration module is used for determining an interface unique identifier, and correspondingly storing the interface unique identifier and the interface executor to finish the registration of the interface.

To achieve the above object, according to a fourth aspect of the present invention, there is provided an interface executing apparatus.

The interface execution device of the present invention comprises: the analysis module is used for responding to an interface call request of the user terminal and analyzing request parameters in the interface call request; the request parameters include: an interface unique identifier; the inquiry module is used for inquiring registered interface information to obtain an interface executor corresponding to the unique interface identifier; and the execution module is used for calling the interface executor and sending the execution result of the interface executor to the user side.

To achieve the above object, according to a fifth aspect of the present invention, there is provided an interface management system.

The interface management system of the present invention includes: the interface registration device is used for analyzing the interface configuration file to obtain interface configuration information; the interface registration device is also used for loading the implementation class of the interface according to the interface configuration information and creating an interface executor based on the implementation class of the interface; the interface registration device is also used for determining an interface unique identifier, and correspondingly storing the interface unique identifier and the interface executor to finish the registration of the interface; the interface executing device is used for responding to an interface calling request of the user side and analyzing request parameters in the interface calling request; the request parameters include: an interface unique identifier; the interface executing device is also used for inquiring registered interface information to obtain an interface executor corresponding to the unique interface identifier; the interface execution device is also used for calling the interface executor and sending the execution result of the interface executor to the user side.

To achieve the above object, according to a sixth aspect of the present invention, there is provided an electronic apparatus.

The electronic device of the present invention includes: one or more processors; and a storage means for storing one or more programs; when the one or more programs are executed by the one or more processors, the one or more processors are caused to implement the interface registration method or the interface execution method of the present invention.

To achieve the above object, according to a fourth aspect of the present invention, a computer-readable medium is provided.

The computer readable medium of the present invention has stored thereon a computer program which, when executed by a processor, implements the interface registration method or interface execution of the present invention.

One embodiment of the above invention has the following advantages or benefits: in the embodiment of the invention, the interface configuration file is analyzed to obtain the interface configuration information, the implementation class of the interface is loaded according to the interface configuration information, the interface executor is created based on the implementation class of the interface, and the steps of storing the unique identifier of the interface and the interface executor are correspondingly stored, so that the registration of the interface is realized. Compared with the existing interface research and development mode based on projects, the interface registration method greatly simplifies the complexity of interface registration or interface release, reduces the technical threshold of interface research and development, and improves the research and development efficiency of interfaces. As the publishing, the management and the maintenance aiming at the granularity of the interfaces are realized, the functions of other interfaces are not affected by the newly added modification change of the interfaces, and the coupling degree between the interfaces is reduced.

Further effects of the above-described non-conventional alternatives are described below in connection with the embodiments.

Drawings

The drawings are included to provide a better understanding of the invention and are not to be construed as unduly limiting the invention. Wherein:

FIG. 1 is an exemplary system architecture diagram in which embodiments of the present invention may be applied;

fig. 2 is a main flow diagram of an interface registration method according to a first embodiment of the present invention;

FIG. 3 is an exemplary routing tree diagram;

FIG. 4 is a schematic flow chart of an interface execution method according to a second embodiment of the present invention;

fig. 5 is a schematic diagram of main modules of an interface registration apparatus according to a third embodiment of the present invention;

FIG. 6 is a schematic diagram of the main modules of an interface execution device according to a fourth embodiment of the present invention;

FIG. 7 is a schematic diagram of the main modules of an interface management system according to a fifth embodiment of the present invention;

fig. 8 is a schematic diagram of a computer system suitable for use in implementing an embodiment of the invention.

Detailed Description

Exemplary embodiments of the present invention will now be described with reference to the accompanying drawings, in which various details of the embodiments of the present invention are included to facilitate understanding, and are to be considered merely exemplary. Accordingly, those of ordinary skill in the art will recognize that various changes and modifications of the embodiments described herein can be made without departing from the scope and spirit of the invention. Also, descriptions of well-known functions and constructions are omitted in the following description for clarity and conciseness.

It should be noted that the various embodiments of the invention and the technical features of the embodiments may be combined with each other without affecting the implementation of the invention.

Fig. 1 illustrates an exemplary system architecture 100 to which an interface registration method or an interface execution method or an interface registration apparatus or an interface execution apparatus or an interface management system of an embodiment of the present invention may be applied.

The user may interact with the server 105 via the network 104 using the terminal devices 101, 102, 103 to receive or send messages or the like. Various communication client applications can be installed on the terminal devices 101, 102, 103.

The terminal devices 101, 102, 103 may be a variety of electronic devices having a display screen and supporting web browsing, including but not limited to smartphones, tablets, laptop and desktop computers, and the like.

The server 105 may be a server providing various services, such as a background management server providing support for an interface management class platform that a user browses with the terminal devices 101, 102, 103.

It should be noted that, the interface registration method or the interface execution method provided by the embodiment of the present invention is generally executed by a server, and accordingly, the interface registration device or the interface execution device is generally disposed in the server.

It should be understood that the number of terminal devices, networks and servers in fig. 1 is merely illustrative. There may be any number of terminal devices, networks, and servers, as desired for implementation.

First embodiment

Fig. 2 is a schematic flow chart of an interface registration method according to a first embodiment of the present invention. As shown in fig. 2, the interface registration method in the embodiment of the present invention includes:

step S201: and analyzing the interface configuration file to obtain interface configuration information.

Before introducing the interface configuration file, the interface file will be described first. An interface file is a system of files that specifies all that is required for some interfaces. The interface file mainly contains the content needed to define an interface. The interface file contains three types of files, namely configuration files, executable files and other additional files of the interface. The configuration file of the interface mainly describes basic information of the interface in a configuration file mode, such as which method of which class the interface is implemented, what is the unique identification of the interface, and the like; the executable file is mainly a program file defining an interface and mainly comprises a program jar package, a dependent jar package and the like, and is a core of operation; other additional files refer to files other than the executable files and interface configuration files, and the user can place some own files as needed. For example, development of some interfaces requires accessing some data, loading some models, or reading some configurations, etc., all of which may exist as additional files in the interface file. The user only needs to access the corresponding file according to the context path of the interface.

In an alternative embodiment, for convenience of maintenance, the interface file adopts a structure similar to the Web project in Tomcat (Tomcat is a Servlet container developed by Jakarta project under Apache software foundation and can be a separate Web server), that is, all files of an interface are placed under a directory, and the name of the directory is a context, that is, a root directory where a user sends an Http request. For example, the configuration file of the interface may be placed under the WEB-INF/WEB directory in the context, and the executable file of the interface may be placed under the WEB-INF/lib directory in the context, and the design of such directory structure is substantially identical to the WEB project of Tomcat, except for the protocols. This is more friendly to maintain and makes it easy for people familiar with Web projects to develop

The interface profile is the core content defining the interface, and the implementation of the interface registration means depends on the interface profile. In particular, the interface configuration file may be in an XML (extensible markup language) file format.

In one alternative example, the interface profile includes: a master library file configuration item, a reference interface file configuration item, an executable file configuration item, an interface implementation class package path configuration item, and an interface implementation class basic information configuration item.

And the main library file configuration item is used for configuring the main library file used by the current interface file. For example, the master library file configuration item may be named base-lib, and is used to designate the master library file used by the current interface file, where the master library file is a directory, and mainly stores a number of universal jar packages, where the universal jar packages are usually related to the technical field, for example, if a MyBatis related technology is required for developing an interface, then the MyBatis related package may be placed in the directory. In the implementation, a plurality of interface files can be used for multiplexing library files under the main library file, and all dependent jar packages do not need to be driven into the interface files, so that the method is lighter. Of course, the main library file is not used, but all jar packages can be driven into the interface file, but by doing so, the interface file is larger, so that the management and maintenance are not facilitated, and if the interface file only comprises the jar package at the very core of the interface execution, the interface file is lighter. In addition, in implementations, there may be one or more of the master library file configuration items base-lib. When multiple base-libs are specified, it is essentially equivalent to adding all base-libs together as a whole.

And the reference interface file configuration item is used for configuring other interface files referenced by the current interface file. For example, the configuration item of the reference interface file may be named as ext-lib, and the configuration item is mainly used for the library file of the current interface file referencing other interface files, so that the flexibility of loading the library file can be further improved. In general, the configuration item can be used when the interface file is dependent, for example, team a develops an NLP field related interface a, team B wants to make some adaptations to the development result of team a, develop a new interface B, and in this case, team B does not need to include all executable files of the interface a developed by team a, but only needs to refer to the library file of the interface a in the interface configuration file.

And the executable file configuration item is used for configuring the executable file of the current interface file. For example, the executable file configuration item may be named Lib, and is mainly used to define the executable file path of the current interface file. In particular implementations, a default executable file path may also be set. For example, when the user does not set the path of the executable file, the executable file may be looked up from a default path (e.g., the default path is WEB-INF/lib).

The interface realization class packet path configuration item is used for configuring the packet file path of the interface realization class under the condition that the interface is defined by an annotating mode. For example, the interface implementation class packet path configuration item may be named base-packet, and mainly defines the packet path for the interface lookup, and this way, the interface is mainly defined by way of annotation. When a user implements an interface class, some annotations such as httpservicer are required to be added, and a certain method of a certain class can be defined as an interface class and a method. In the case of interface classes defined in an annotated manner, it is only necessary to provide a base-package parameter which tells the interface registration means from which package to load the interface class.

An interface implementation class basic information configuration item, configured to configure basic information of an interface implementation class in a case that an interface is defined by a configuration manner, where the basic information of the interface implementation class includes: the class name of the interface implementation class, and the method name used. For example, the interface implementation class basic information configuration item may be named as server-class, which defines the interface implementation class by a configuration method, which needs to be written in an interface configuration file, and which method of which class the interface is implemented by. In addition, the server-class can also write information such as unique identification of the open interface. In addition, in the implementation, considering that the configuration item base-package and the configuration item server-class can be used for defining the interface information, the interface configuration file only needs to include one of the configuration item base-package and the configuration item server-class.

In another alternative example, the interface configuration file includes a file download path configuration item, a global parameter list configuration item, in addition to a master library file configuration item, a reference interface file configuration item, an executable file configuration item, an interface implementation class package path configuration item, and an interface implementation class basic information configuration item.

The file download path configuration item can be named as a download, the configuration item is used for defining a path of file download, if a request is sent to the path configured by the download configuration item, a result is returned in a file download mode, and a user can download the file at a browser side. The configuration mainly provides support for a file downloading function, and the interface registration device can dynamically modify the request head of the request according to the configuration item and add some parameters to realize the downloading function.

Global parameter list configuration items, which may be named param-list, define a global parameter list that can be accessed in a context cache, and which can be accessed by a user when implementing an interface class.

In one exemplary scenario, in response to an interface registration request from a user side, the interface registration apparatus begins executing the interface registration method flow shown in fig. 2. After receiving the interface registration request of the user, the interface registration device accesses the interface configuration file and analyzes the interface configuration file to obtain interface configuration information. The interface configuration information includes parameter information configured under each interface configuration item, such as parameter information under a server-class configuration item, and the like.

In another exemplary scenario, the interface registration device scans interface files under a specified directory at regular time, loads legal interface files, and registers according to the flow shown in fig. 2.

In an alternative embodiment, in order to implement management and control on the version of the interface file, a timestamp, a delete flag (such as a delete flag bit) and other suffix information are added to the file name of the interface file. Specifically, the file name of the interface file may be divided using a separator such as a space, the first part being an interface context (context), and the next part being a timestamp. The time stamp may be a time of a current time given by the system when the user uploads the interface file. In addition, when a user deletes one interface file, a delete flag "delete" may be added after the suffix of the file name of the interface file is set to delete, that is, after the context and the timestamp included in the interface file name. In this alternative embodiment, legal interface files may be loaded according to the following: scanning all interface files under a specified directory (for example, the specified directory is webapp), classifying all interface files according to interface contexts (contexts), then removing interface files with deletion marks, sorting the interface files under each category according to time stamps, and loading and registering the interface file with the largest time stamp under the category. Thus, all the history versions of the same interface context can be checked by only scanning all the interface files (including different time stamps and the released flag) under the same context category, and the versions can be managed and maintained, for example, one interface version of the history can be restored to the current version to realize rollback of the interface.

Step S202: and loading the implementation class of the interface according to the interface configuration information, and creating an interface executor based on the implementation class of the interface.

Optionally, before step S202, the method of the embodiment of the present invention further includes: creating a custom class loader to dynamically load the implementation class of the interface according to the interface configuration information through the custom class loader, and creating an interface executor.

Because dynamic loading is used, the hot deployment of the interface can be realized, namely the upgrading of the interface can be completed without restarting the server; isolation of the execution code may be achieved between class two loaders. The different interface files are implemented by different class loaders, and the different interface file execution code is isolated from the class loader level. For example, the technical framework used by one interface file may conflict with another interface file, and no problem exists in execution because the two interface files are isolated at the loader level. Since the code is isolated at the loader level, when a user develops an interface file, only the library and the dependent environment inside one interface file need to be considered, and the relation with other interface files does not need to be considered.

In an alternative embodiment, the custom class loader is designed to include: the top-most class of loader (also called Base class loader), the second class of loader inherited from the first class of loader (also called Ext loader), the third class of loader inherited from the second class of loader (also called interface file class loader). That is, the first type of loader is a parent loader of the second type of loader, and the second type of loader is a parent loader of the third type of loader. The first class loader is used for loading the package files under all paths configured under the configuration items of the main library file; the second class loader is used for loading the package files under all paths configured under the reference interface file configuration items; and the third class loader is used for loading the package files under all paths configured under the executable file configuration items.

That is, the third class loader is mainly used to load jar packets packaged in the interface files, while the first class loader and the second class loader are used to offload the interface files, and some more general jar packets can be placed in these loaders, so that multiple interface files are demultiplexed, thus reducing the size of each interface file and avoiding the need to punch the same jar packets into each interface file. For example, output log function may be required for writing all interface files, then the jar packet related to the output log function may be required to be called in each interface file, and at this time, the jar packet related to the output log function may be put into the Base class loader, so that each interface file does not need to package the jar packet related to the output log function.

When a new class is loaded in the Java virtual machine, the new class is unloaded from the bottom loader, if the new class is not found, the loading from the parent loader is tried, and if the new class is not found, the loading is continued from the previous-level loader until the loading is successful; if none is found from the top-level loader, the exception is thrown. According to this loading logic, when a class exists in both the third class loader and the first class loader, then the third class loader is loaded.

The class loading mechanism based on the java virtual machine has the following advantages that the custom class loader designed by the optional embodiment has: the class provided in the interface file can be ensured to have higher priority, and further, when it is not clear whether a jar packet exists in the parent loader, the packet can be packed into the interface file, so that no problem can be guaranteed to be executed, no abnormality that the class file (classnotFoundException) cannot be found can occur, at most, the jar packet also exists in the parent loader, however, the jar packet existing in the child loader is subject to, and in addition, when the versions of the jar packet in the parent loader and the jar packet in the child loader are inconsistent, the packet in the child loader is subject to.

Illustratively, in step S202, the third class loader at the bottom is invoked to load the package files under all paths configured under the executable file configuration item, then creates an interface instance object through a reflection mechanism, and encapsulates the invocation of the corresponding method to form an interface executor. Specifically, the implementation class of the interface may be loaded in two ways: the first way is that, in the case that the interface implementation class packet path configuration item is not empty, all class files under the packet file path configured by the interface implementation class packet path configuration item are scanned so as to load the class files with notes from the class files. Compared with the method for directly searching the class files with the notes from all the class files, the method has the advantages that the basic package for searching is set in the configuration item base-package in the configuration file in advance, a searching range is defined, and all the class files under the basic package configured by the configuration item base-package are scanned, so that the class files with the notes are found out, and the efficiency of searching the class files with the notes is greatly improved. The second way is that, under the condition that the interface implementation class basic information configuration item is not empty, the implementation class of the basic information loading interface of the interface implementation class is specified according to the interface implementation class basic information configuration item.

Step S203: and determining an interface unique identifier, and correspondingly storing the interface unique identifier and the interface executor to finish the registration of the interface.

The method comprises the steps that an interface registration device dynamically creates a class loader according to the description in the configuration file, loads a corresponding class, creates an interface object instance, encapsulates the call of a corresponding method to form an interface executor, and correspondingly stores the created interface executor and an interface unique identifier.

Illustratively, in step S203, an interface unique identification may be parsed from the interface configuration file. The interface unique identifier is used to distinguish which interface is called, such as the id of the same interface. The interface unique identifier is also a parameter in nature, but this parameter is relatively specific and corresponds to the naming of an interface for uniquely identifying an interface. The interface unique identification may be defined in a number of ways, such as by a request parameter name.

In an alternative embodiment, request routing is employed as the interface unique identification. Request routing is understood to be the routing of requests, which is multi-level. For example, when the Http request is "https:// www.xiaohongshu.com/discovery/item/5f9f6d9f00000000010072b4 id=1001 & session=sldfjkljwerjlsfjlsdfj", the "https:// www.xiaohongshu.com" in the request is the domain name of the website, similar to the information of the ip and port of the request, the "discovery/item/5f9f6d9f00000000010072b" is the request route, and "? The "latter part" id=1001 & session=sldfjkljwerjlsdffjlsdfj "is the parameter of the request. In this example, the various levels of routing parameters for the request routing are separated by "/", a process similar to the file directory structure of an operating system, and one folder may contain one or more files. Similarly, one route may include one or more sub-routes, e.g., a "discover/item/" route may include a "discover/item/129798345924342" route, and a "discover/info" route may include a "discover/info" route. It can be seen that the basic form of a route is a tree structure, a route may contain one or more child routes, each subordinate to a parent route, that is, a child route will prefix the parent route.

When the request route is adopted as the unique interface identifier, the storing the unique interface identifier and the interface executor correspondingly comprises the following steps: adding the request route of the interface to a route tree; the route corresponding to the request route in the route tree comprises one or more nodes, and each node is used for storing the route parameters of the corresponding level contained in the request route; and storing corresponding interface executors at the final nodes of the paths corresponding to the request routes of the interfaces.

Fig. 3 is an exemplary routing tree diagram. As shown in fig. 3, a path from the root node to any child node is represented as a request route. For example, the request route discovery/item/aaa corresponds to a path in the route tree formed by the node discovery, the node item and the node aaa; request route discovery/item/bbb, corresponding to the route formed by node discovery, node item and node bbb in the route tree; the request route discovery/item/ccc corresponds to a path formed by a node discovery, a node item and a node ccc in the route tree. The tree structure of the Http routing request is fully considered by the routing tree shown in fig. 3, and the interface information is stored in a storage mode of the routing tree, so that the hierarchical quick search of the routing is facilitated. In the specific implementation, all the sub-nodes of each node can be stored in one HashMap (HashMap is a non-synchronous implementation of a map interface based on a Hash table), so that when each node searches for a specific sub-node, a Hash (Hash) searching mode can be utilized, and the route searching efficiency is greatly improved.

In the routing tree shown in fig. 3, there may be three actuators on each node in the routing tree, respectively, an actuator corresponding to a post request (which may be named PostHandler), an actuator corresponding to a get request (which may be named GetHandler), and an actuator corresponding to a file upload request (which may be named FileHandler), which default to null, indicating that there are no such three actuators by default. Only when registering an interface will the corresponding interface executor be added at the final node of the path according to the request type. For example, the unique identifier of the interface to be registered is/discover/item/aaa, then the multi-level routing parameters contained in the request route are added to the routing tree to construct a path composed of nodes discover, node item and node aaa, and then an interface executor is added to the final node aaa of the path according to the request type of the interface. For example, assuming that the interface request type is a post request, the enforcer PostHandler is set to a at the last level node, thus completing the registration of the interface.

In the interface profile mode, the request route of the interface may be defined by uri attributes. The class and the method have uri attributes, the uri attributes of the class and the uri attributes of the method are spliced together, and then the interface file name is supplemented to form a complete route. For example: under the interface file nlp, there is a class whose uri is system and whose uri is interface/manager, then the complete route of this interface method is: nlp/system/interface/manager can be located to the method through this route. The annotation method is similar when used to define routes, except that the uri attribute will be replaced by the value attribute of the httpdevice annotation, with the rest of the processing logic being consistent with the configuration file.

In the embodiment of the invention, the registration of the interface is realized through the steps. Compared with the existing interface research and development mode based on projects, the interface registration method greatly simplifies the complexity of interface registration or interface release, reduces the technical threshold of interface research and development, and improves the research and development efficiency of interfaces. As the publishing, the management and the maintenance aiming at the granularity of the interfaces are realized, the functions of other interfaces are not affected by the newly added modification change of the interfaces, and the coupling degree between the interfaces is reduced.

Second embodiment

Fig. 4 is a schematic flow chart of an interface execution method according to a second embodiment of the present invention. As shown in fig. 4, the interface execution method of the embodiment of the present invention includes:

step S401: responding to an interface call request of a user side, and analyzing request parameters in the interface call request; the request parameters include: the interface is uniquely identified.

Illustratively, in step S401, corresponding parameters are parsed from the interface call request of the user terminal, where the parameters mainly include the unique identifier of the interface, and may further include a request type (such as a post request or a get request), a request header, a request body (typically, only the post request has the request body), and so on. After each request parameter is analyzed, the request parameter can be stored in one HashMap, so that the subsequent access is convenient, and preparation is made for calling an interface executor.

The interface unique identifier is also a parameter in nature, but this parameter is relatively specific and corresponds to the naming of an interface for uniquely identifying an interface. The interface unique identification may be defined in a number of ways, such as by a request parameter name. In an alternative embodiment, request routing is employed as the interface unique identification.

Optionally, before step S402, the interface execution method according to the embodiment of the present invention further includes the following steps: based on the request parameters analyzed in step S401, some system-level processes are performed, and mainly, some technical frameworks, platform integration work, some general processes, etc., such as authority verification, login information verification, and Token verification, etc., are completed.

Step S402: and querying the registered interface information to obtain an interface executor corresponding to the unique interface identifier.

In an alternative example, the interface is uniquely identified as a request route for the interface, and the registered interface information is stored in the form of a route tree. After the request route of the interface is parsed in step S401, splitting the request route of the interface into a plurality of levels of routing parameters to obtain an array composed of the plurality of levels of routing parameters; performing path retrieval in the routing tree according to the array; and under the condition that the path corresponding to the request route is retrieved, acquiring an interface executor corresponding to the request type of the interface call request from a final node of the path.

For example, assuming that the parsed request route is "discover/item/aaa", the routing parameters are then split according to the delimiter "/", and an array of discovery, item, aaa is obtained. And then, for each element in the array, sequentially searching from a pre-constructed route tree, and if a route corresponding to the request route is searched, acquiring a corresponding interface executor from a final node of the route according to the request type. For example, if the request type is a post request, an interface executor corresponding to the post request is obtained from the final node; for example, if the request type is a get request, the interface executor corresponding to the get request is obtained from the last-stage node.

Further, the user may also specify a retrieval policy in the configuration file and the annotation. For example, the search policy may be set to a full match search policy, a prefix match, a suffix match, or a wild card match, etc. Each search strategy is essentially a query algorithm for the routing tree described above. In addition, the user can realize the route retrieval interface by himself and define the route retrieval strategy by himself. Because of supporting diversified route retrieval strategies, the retrieval logic of the user on the route can be enriched, and the user can define more complex and flexible interfaces.

Step S403: and calling the interface executor and sending an execution result of the interface executor to the user side.

In an alternative example, after the last level node is retrieved from the routing tree, an interface executor on the last level node (such as an interface executor PostHandler corresponding to the post request or an interface executor GetHandler corresponding to the get request, etc.) is obtained according to a request type (such as the post request or the get request). If a corresponding interface actuator is acquired, the interface actuator can be called according to the analyzed interface entry.

Further, in the above-described alternative example, the interface execution method may further include the steps of: and searching an interface file corresponding to the request route from an interface file storage path and returning a query result to the user side under the condition that a path corresponding to the request route is not retrieved from the route tree or an interface executor corresponding to the request type of the interface call request is not obtained from the final-stage node of the path corresponding to the request route. When the method is implemented, if the interface file corresponding to the request route is successfully acquired from the interface file storage path, the interface file content is returned, and if the interface file corresponding to the request route is not acquired, the exception is thrown out. In this way, access to static resource files can be supported in the interface file.

In the above alternative examples, when the route of the interface request is added to the route tree, the corresponding interface executor can be quickly retrieved from the route tree, and then the method of the interface executor is invoked. Based on the characteristics, the user can realize the management and maintenance of the interface only by managing the route on a certain server. For example, if a certain interface is controlled to be opened or closed, only whether a certain route is effective or not needs to be controlled, and the strategy enables the user to control the interface very flexibly and finely.

Optionally, in step S403, when the interface method is called for processing, the four processes of parameter adaptation, preprocessing module call, post-processing module call, and result set adaptation are mainly involved. The core process is a parameter adaptation and result set adaptation process.

When a method is called, it is necessary to refer to the method. Considering that parameters are delivered by the user via some data formats, it may be necessary to adapt these parameter formats before delivering them to the corresponding methods. For example, when a user sends an Http request, the user's request parameters often have a particular format. For example, when a user sends a post request, the post request includes a request body that encapsulates data information in a specific format, more commonly in json (a lightweight data exchange format), but also encapsulates Base64 (Base 64 is one of the common encoding schemes used to transmit 8Bit bytecodes on a network, which is a method for representing binary data based on 64 printable characters) or other serialized data structures. The request body is encapsulated with data, and only a corresponding data processing protocol is added, what transmission method is used by the front end, and the back end is analyzed by adopting a corresponding method. In addition, when the calling end uploads the file, the request body contains the data stream of the file, and the back end needs to process the data stream, for example, the data stream of the file is stored in a place, so that the file uploading service is completed.

The interface service method needs to define a processing method get/post to determine the user request that can be processed by the interface service method. For example, if the interface service method is configured with a processing method of a post type, this interface can only be used to process a user's post request, and if the interface service method is configured with a processing method of a get type, this interface can only be used to process a user's get request.

After the parameters entered by the user are adapted, they are passed to the corresponding method. Specifically, the parameter delivery method includes default and active parameter delivery. The default parameter transmission is a parameter transmission mode through a data type, and an exemplary flow is as follows: if the interface service method is of get type, the request parameters in the key-value (key-value pair) form resolved from the request are packaged into a Map object (RequestMap) by default, then the Map object is transmitted to the parameters of java. Uteil. Map type in the interface service method, and if the interface service method does not contain the parameters of java. Uteil. Map type, the processing is not performed; if the interface service method is of post type, the request body needs to be transferred to the interface service method based on the above Map type parameter transfer. The request body transmission firstly judges whether the file stream is contained, if the file stream is contained, the file stream is transmitted to the file stream object of the interface service method, otherwise, the request body is transmitted to the String (character String) type object of the interface service method.

The method of proactive transfer of a specific request parameter to a specific parameter of an interface service method, primarily through configuration and annotation, is exemplified as follows: if the method is a configuration method, the value configured by the request-parameter node under the method node is used as a parameter name, the parameter name is used as a key, the value is obtained from the Map object request Map, and then the value is sequentially transmitted to an interface service method; if the annotation mode is the annotation mode, when a user is required to write an interface service method, adding a RequestParam (request parameter) annotation to a specific method parameter, then taking the annotated value as a key (key) of the parameter, acquiring a value from a Map object RequestMap, and transmitting the value to the specific parameter.

Preprocessing is mainly to insert a process before the interface service method is called, and post-processing is mainly to insert a process after the result is returned. Both the preprocessing module and the post-processing module can access the parameter information requested by the user, the basic information such as the request head and the like, and the variables of some contexts and the like. In addition, the post-processing module may also access the user's return value information. The preprocessing module and the post-processing module can support a user to register realization classes of some preprocessors and post-processor interfaces in a configuration mode, and complete preprocessing and post-processing functions appointed by the user.

The design of the preprocessing and post-processing module can enable a user to add some general processing methods for a batch of interface registration in a section programming mode. Such as performance monitoring, throttling, session checking for the user, etc. The general functions can be realized in the preprocessing and post-processing functional modules without being realized in the process of writing an interface service method by a user, so that the general functions and some specifications of a platform framework can be deeply decoupled from an interface of the user, and when the user realizes interface service logic, the user does not need to care about the realization, and the corresponding processing function is added when the interface is registered.

The result set adaptation is mainly to adapt the return value of the interface service method to a unified format, and because the interface service method may be successfully executed or may fail to be executed, if the execution is successful, the return value of the result needs to be returned to the caller, and if the execution is failed, the information related to the failure needs to be returned to the caller, so that the caller can process the return result in a unified manner, and in addition, the abnormal information of the execution can be obtained, so that the corresponding judgment on the interface execution condition can be conveniently made.

An exemplary result set adaptation scheme is as follows: the returned result contains parameters of three cores, namely result, data and info, wherein the result is the result of the execution, if 0 indicates that the execution is successful, if 1 indicates that the execution is abnormal, and if 2 indicates that the warning is generated; data represents the data returned by the request, and is generally returned in json format, although other serialized data formats can be adopted; info is the description information of the current execution. In general, when result is 0, data is valid, and when result is not 0, data is invalid, and info is valid, which means that exception information is abnormal, that is, when an exception occurs in execution, the system will set result returned to 1, and place the exception information into info attribute, and return the exception information to the calling end. The result set adapting logic has a plurality of advantages, namely, all conditions such as return value and exception handling can be solved, all functions are met, the processing mode enables a calling party to have a unified data return format for all results, the calling party can process the results conveniently, and thirdly, a user can avoid processing the traditional complex Http return state code, and success and failure are clear at a glance.

The result set adaptation function may be turned off by means of notes and configuration. If the result set adapting function is closed, when the method is successfully executed, the native return value of the method is sent to the calling party in json mode, and when the method is failed to be executed, the native return value is returned to the specific Http state code of the calling party.

In the embodiment of the invention, the efficient and rapid interface operation is realized through the steps. Compared with the existing interface research and development mode based on the project, the interface execution method of the invention greatly simplifies the complexity of interface execution, reduces the technical threshold of interface research and development, and improves the research and development efficiency of the interface. Because the operation, the management and the maintenance aiming at the granularity of the interfaces are realized, the functions of other interfaces are not affected by the newly added modification change of the interfaces, and the coupling degree between the interfaces is reduced.

Third embodiment

Fig. 5 is a schematic diagram of main modules of an interface registration apparatus according to a third embodiment of the present invention. As shown in fig. 5, an interface registration apparatus 500 according to an embodiment of the present invention includes: parsing module 501, loading module 502, registration module 503.

The parsing module 501 is configured to parse the interface configuration file to obtain interface configuration information.

In one exemplary scenario, in response to an interface registration request from a user side, an interface registration device begins performing an interface registration procedure. After receiving the interface registration request of the user, the interface registration device accesses the interface configuration file and analyzes the interface configuration file to obtain interface configuration information. The interface configuration information includes parameter information configured under each interface configuration item, such as parameter information under a server-class configuration item, and the like.

In another exemplary scenario, the interface registration device scans interface files under a specified directory at regular time, and loads and registers legal interface files.

And the loading module 502 is configured to load an implementation class of the interface according to the interface configuration information, and create an interface executor based on the implementation class of the interface.

Optionally, the interface registration device of the embodiment of the present invention further includes: and the loader creating module is used for creating a custom class loader so as to dynamically load the implementation class of the interface according to the interface configuration information through the custom class loader and create an interface executable.

In one alternative example, a custom class loader is designed comprising: the top-most class of loader (also called Base class loader), the second class of loader inherited from the first class of loader (also called Ext loader), the third class of loader inherited from the second class of loader (also called interface file class loader). That is, the first type of loader is a parent loader of the second type of loader, and the second type of loader is a parent loader of the third type of loader. The first class loader is used for loading the package files under all paths configured under the configuration items of the main library file; the second class loader is used for loading the package files under all paths configured under the reference interface file configuration items; and the third class loader is used for loading the package files under all paths configured under the executable file configuration items.

Further, when the custom class loader of the above example is adopted, the loading module 502 loads the implementation class of the interface according to the interface configuration information, and creating the interface executor based on the implementation class of the interface may specifically include: and calling a third class loader at the bottom layer to load the package files under all paths configured under the executable file configuration items, then creating an interface instance object through a reflection mechanism, and encapsulating the calling of the corresponding method to form an interface executor. Specifically, the load module 502 may load the implementation class of the interface in two ways: the first way is that, in the case that the interface implementation class packet path configuration item is not empty, all class files under the packet file path configured by the interface implementation class packet path configuration item are scanned so as to load the class files with notes from the class files. Compared with the method for directly searching the class files with the notes from all the class files, the method has the advantages that the basic package for searching is set in the configuration item base-package in the configuration file in advance, a searching range is defined, and all the class files under the basic package configured by the configuration item base-package are scanned, so that the class files with the notes are found out, and the efficiency of searching the class files with the notes is greatly improved. The second way is that, under the condition that the interface implementation class basic information configuration item is not empty, the implementation class of the basic information loading interface of the interface implementation class is specified according to the interface implementation class basic information configuration item.

And the registration module 503 is configured to determine an interface unique identifier, and store the interface unique identifier and the interface executor in correspondence to complete registration of the interface.

Illustratively, the registration module 503 may obtain the interface unique identifier from the parsing result of the parsing module. The interface unique identifier is used to distinguish which interface is called, such as the id of the same interface. The interface unique identifier is also a parameter in nature, but this parameter is relatively specific and corresponds to the naming of an interface for uniquely identifying an interface. The interface unique identification may be defined in a number of ways, such as by a request parameter name.

When the request route is adopted as the unique interface identifier, the registration module 503 stores the unique interface identifier and the interface executor correspondingly, including: the registration module 503 adds the request route of the interface to the route tree; the route corresponding to the request route in the route tree comprises one or more nodes, and each node is used for storing the route parameters of the corresponding level contained in the request route; registration module 503 stores the corresponding interface executors at the final nodes of the paths corresponding to the request routes of the interfaces.

In the embodiment of the invention, the registration of the interface is realized through the device. Compared with the existing interface research and development mode based on projects, the interface registration device greatly simplifies the complexity of interface registration or interface release, reduces the technical threshold of interface research and development, and improves the research and development efficiency of interfaces. As the publishing, the management and the maintenance aiming at the granularity of the interfaces are realized, the functions of other interfaces are not affected by the newly added modification change of the interfaces, and the coupling degree between the interfaces is reduced.

Fourth embodiment

Fig. 6 is a schematic diagram of main modules of an interface execution device according to a fourth embodiment of the present invention. As shown in fig. 6, an interface execution apparatus 600 of an embodiment of the present invention includes: a parsing module 601, a query module 602, and an execution module 603.

The parsing module 601 is configured to parse request parameters in an interface call request in response to the interface call request of a user side. Wherein the request parameters include: the interface is uniquely identified.

Illustratively, the parsing module 601 parses corresponding parameters from an interface call request of the user side, where the parameters mainly include an interface unique identifier, and may further include a request type (such as a post request or a get request), a request header, a request body (typically, only the post request has the request body), and so on. After each request parameter is analyzed, the request parameter can be stored in one HashMap, so that the subsequent access is convenient, and preparation is made for calling an interface executor.

Optionally, the interface executing device of the embodiment of the present invention further includes: the system-level processing module is configured to perform some system-level processing based on the request parameters analyzed by the analysis module 601, where the system-level processing mainly completes some technical frameworks, integration work of the platform, some general processing, and the like, such as authority verification, login information verification, some Token verification, and the like.

And the query module 602 is configured to query the registered interface information to obtain an interface executor corresponding to the unique interface identifier.

In an alternative example, the interface is uniquely identified as a request route for the interface, and the registered interface information is stored in the form of a route tree. After the request route of the interface is parsed by the parsing module 601, the request route of the interface is split into a plurality of levels of routing parameters, so as to obtain an array composed of the plurality of levels of routing parameters. Next, the query module 602 performs path retrieval in the routing tree according to the array; and under the condition that the path corresponding to the request route is retrieved, acquiring an interface executor corresponding to the request type of the interface call request from a final node of the path.

For example, assuming that the parsed request route is "discover/item/aaa", the routing parameters are then split according to the delimiter "/", and an array of discovery, item, aaa is obtained. Then, for each element in the array, the query module 602 sequentially retrieves from the pre-built routing tree, and if a path corresponding to the requested route is retrieved, the query module 602 obtains a corresponding interface executor from a final node of the path according to the request type. For example, if the request type is a post request, the query module 602 obtains an interface executor corresponding to the post request from the final node; for example, if the request type is a get request, the query module 602 obtains the interface executor corresponding to the get request from the last level node.

And the execution module 603 is configured to invoke the interface executor and send an execution result of the interface executor to the user side.

In an alternative example, after the last level node is retrieved from the routing tree, an interface executor on the last level node (such as an interface executor PostHandler corresponding to the post request or an interface executor GetHandler corresponding to the get request, etc.) is obtained according to a request type (such as the post request or the get request). If a corresponding interface actuator is obtained, the execution module 603 may then call the interface actuator according to the parsed interface enrollment.

Further, in the above alternative examples, the query module 602 may also be configured to: and searching an interface file corresponding to the request route from an interface file storage path and returning a query result to the user side under the condition that a path corresponding to the request route is not retrieved from the route tree or an interface executor corresponding to the request type of the interface call request is not obtained from the final-stage node of the path corresponding to the request route. In implementation, if the query module 602 successfully obtains the interface file corresponding to the request route from the interface file storage path, the content of the interface file is returned, and if the interface file corresponding to the request route cannot be obtained, the exception is thrown. In this way, access to static resource files can be supported in the interface file.

In the embodiment of the invention, the device realizes the efficient and quick interface operation. Compared with the existing interface research and development mode based on projects, the interface execution device provided by the invention has the advantages that the complexity of interface execution is greatly simplified, the technical threshold of interface research and development is reduced, and the research and development efficiency of the interface is improved. Because the operation, the management and the maintenance aiming at the granularity of the interfaces are realized, the functions of other interfaces are not affected by the newly added modification change of the interfaces, and the coupling degree between the interfaces is reduced.

Fifth embodiment

Fig. 7 is a schematic diagram of main modules of an interface management system according to a fifth embodiment of the present invention. As shown in fig. 7, an interface management system 700 of an embodiment of the present invention includes: an interface registration device 701 and an interface execution device 702.

An interface registration device 701, configured to add a business logic implementation class developed by a user to a system service. The interface registration device 701 loads, creates an instance, adapts, and completes a series of operations such as route registration on an interface file under a specified path (such as a webapp path), so that the interface may be used on line.

The interface registration device 701 includes an parsing module, a loading module, and a registration module. The analysis module is used for analyzing the interface configuration file to obtain interface configuration information; the loading module is used for loading the implementation class of the interface according to the interface configuration information and creating an interface executor based on the implementation class of the interface; and the registration module is used for determining an interface unique identifier, and correspondingly storing the interface unique identifier and the interface executor to finish the registration of the interface.

For a detailed description of each module in the interface registration device, reference may be made to the related description of the third embodiment, which is not repeated here.

Interface execution means 702 for implementing the call and operation of the registered interface executor. The interface execution device 702 includes: the system comprises an analysis module, a query module and an execution module. The analysis module is used for responding to an interface call request of the user side and analyzing request parameters in the interface call request; the request parameters comprise an interface unique identifier; the inquiry module is used for inquiring the registered interface information to obtain an interface executor corresponding to the unique interface identifier; and the execution module is used for calling the interface executor and sending the execution result of the interface executor to the user side.

For a detailed description of each module in the interface executing device, reference may be made to the related description of the fourth embodiment, which is not repeated here.

Optionally, the interface management system 700 further includes: public system service device and public data buffer pool.

The public system service device is mainly used for managing interfaces and mainly comprises metadata service, file management service, monitoring service and route management service.

The metadata service mainly describes metadata information of interfaces, namely, mainly comprises which interfaces, how the interfaces call, how the performance and the like.

The file management service is mainly used for managing and maintaining related files of the interface. For example: executable files, configuration files, and other additional data files, etc.

The listening service is mainly a support for distributed management of interfaces. For example, the listening service may employ a master-slave mode, i.e. there is a heartbeat detection between the slave node and the master node, which service mainly synchronizes some information of the slave node to the master node. Thus, the user can check the interface metadata information of all nodes only by accessing the master node. In addition, when the master node changes, the master node can issue some commands to enable the slave node to automatically complete upgrading operation, so that a user only needs to manage the interfaces of the master node (such as adding or deleting some interfaces), the slave node can automatically update the changes from the master node, and the update condition is returned to the master node, thereby being convenient for checking the upgrading condition of the interfaces of all the sub-nodes.

The route management service is mainly the management of routes, such as adding and deleting some routes. The route management service mainly provides technical guarantee similar to database transaction when the interface is newly added and modified, can realize that the route can be modified only after the interface is successfully upgraded, and supports rollback operation of the interface, namely, the new version interface is rolled back to a certain historical version. In addition, through the related technology of route management, service 0 delay in upgrading and modifying an interface can be realized, namely, the switching from the old version interface to the new version interface does not have service interruption.

The specific route management strategy is as follows: when an interface is created, only when an interface instance is completely created successfully, a route is added, otherwise, the interface is prompted to fail to upgrade, and only after the route is created successfully, the service can be normally used; when an interface is upgraded, only when the executor of the interface is successfully created, the execution of the new version of the interface is ensured to have no problem, and then a route is replaced, namely the executor of the interface is replaced by a new one, and the unique identifier of the interface is not modified; in addition, when the interface is upgraded, the interface can be issued to a temporary route, self-test is carried out first, and when the self-test has no problem, the old version interface route is replaced, so that the mode can ensure the stability of the interface to the maximum extent, and when the stability of some interface services is higher, the strategy can be considered to be adopted, and the strategy can provide further test before the online for users.

The public data cache pool mainly completes the data storage function. The data mainly comprises interface metadata, routing information, a context loader, an interface executor and the like, and the storage of the data is simple, and mainly designs a reasonable data structure, saves some memory objects, and can quickly search and access the objects.

In the embodiment of the invention, the interface management system can greatly reduce the technical threshold for developing the interface, greatly improve the development efficiency of the interface and reduce the complexity of interface management. By using the system, the development of the interface is very concise, the local executable can be released on line, and the platform can be used for solving the requirements of interface management and development of enterprises. Specifically, the interface management system in the embodiment of the invention can realize at least one of the following beneficial effects:

1. the scheme supports the creation of the configuration file mode to realize the example and the calling of the method, and is developed into an interface, so that the complexity of the research and development of the interface is greatly simplified. Many times, for some open source technical implementations, a user may issue a configuration file as an interface without writing any code, and only by maintaining a section of configuration file.

2. The scheme designs a mechanism of a class loader for each interface file independently, so that different interface files have independent execution systems and execute without interference, and thus, the newly developed interfaces cannot influence the interfaces of the old version. In addition, when the user develops the interface, the compatibility problem of other interfaces, such as the packet collision problem, is not required to be considered, and only the execution of the current interface is required to be considered, so long as the current interface is ensured to be executable, the interface is deployed into the environment, and the execution is ensured to be executable.

3. The scheme adopts the technology of the interface executor, can weave some preprocessors and post-processors before and after the interface executor, can realize some platform functions and technologies in the processors, and does not need to consider the technologies when a user realizes the interface. Therefore, the realization details of the interface can be completely decoupled from the technical framework and specification of the platform, the technologies are transparent to users, and the users only need to care about the business logic of the interface. The complexity of developing the interface by the user is greatly simplified, so that the interface project becomes lighter and is easy to manage and maintain.

4. The scheme realizes the tree-shaped route management strategy, and only the route is successfully established, and the interface side can play a role. The technology ensures that the management and maintenance of the interface are more flexible and reliable, and the interface supports hot deployment without interrupt upgrading by matching with a custom class loader and a class dynamic loading mechanism.

5. The scheme supports various route retrieval strategies, and the user can customize the route retrieval strategies, based on the technology, the user can define a plurality of more powerful interfaces, such as the template interfaces

6. The executable files contained in the interface files maintained by the scheme are not source codes, and the interface upgrading process can realize dynamic loading without compiling. The reliability and the upgrading efficiency are greatly improved. As online compilation may fail and also consume server resources.

7. The scheme realizes a distributed one-master-multiple-slave monitoring service architecture, supports a distributed environment, can automatically synchronize to each sub-service when some interfaces of the master service change, and can automatically update each sub-service only by managing and maintaining the interfaces above the master service.

8. The scheme supports resource allocation of interface granularity, namely the node number of a certain interface configuration can be configured, and the prior case can only control the granularity of items. For example: the technology can control the regulation and control of resources at the interface granularity, and can precisely control the number of service nodes of any one interface, so that the regulation and control of the resources are more precise and fine, and the resource utilization rate of a server is more easily in a reasonable range. When a certain interface is found to be called very frequently, the number of nodes of the interface can be directly expanded. In the prior art, the node number of the item where the interface is located can be only expanded, and the regulation and control of the resource are coarser.

Referring now to FIG. 8, there is illustrated a schematic diagram of a computer system 800 suitable for use in implementing an electronic device of an embodiment of the present invention. The computer system shown in fig. 8 is merely an example, and should not be construed as limiting the functionality and scope of use of embodiments of the present invention.

As shown in fig. 8, the computer system 800 includes a Central Processing Unit (CPU) 801 that can perform various appropriate actions and processes according to a program stored in a Read Only Memory (ROM) 802 or a program loaded from a storage section 808 into a Random Access Memory (RAM) 803. In the RAM 803, various programs and data required for the operation of the system 800 are also stored. The CPU 801, ROM 802, and RAM 803 are connected to each other by a bus 804. An input/output (I/O) interface 805 is also connected to the bus 804.

The following components are connected to the I/O interface 805: an input portion 806 including a keyboard, mouse, etc.; an output portion 807 including a display such as a Cathode Ray Tube (CRT), a Liquid Crystal Display (LCD), and a speaker; a storage section 808 including a hard disk or the like; and a communication section 809 including a network interface card such as a LAN card, a modem, or the like. The communication section 809 performs communication processing via a network such as the internet. The drive 810 is also connected to the I/O interface 805 as needed. A removable medium 811 such as a magnetic disk, an optical disk, a magneto-optical disk, a semiconductor memory, or the like is mounted on the drive 810 as needed so that a computer program read out therefrom is mounted into the storage section 808 as needed.

In particular, according to embodiments of the present disclosure, the processes described above with reference to flowcharts may be implemented as computer software programs. For example, embodiments of the present disclosure include a computer program product comprising a computer program embodied on a computer readable medium, the computer program comprising program code for performing the method shown in the flow chart. In such an embodiment, the computer program may be downloaded and installed from a network via the communication section 809, and/or installed from the removable media 811. The above-described functions defined in the system of the present invention are performed when the computer program is executed by a Central Processing Unit (CPU) 801.

The computer readable medium shown in the present invention may be a computer readable signal medium or a computer readable storage medium, or any combination of the two. The computer readable storage medium can be, for example, but not limited to, an electronic, magnetic, optical, electromagnetic, infrared, or semiconductor system, apparatus, or device, or a combination of any of the foregoing. More specific examples of the computer-readable storage medium may include, but are not limited to: an electrical connection having one or more wires, a portable computer diskette, a hard disk, a Random Access Memory (RAM), a read-only memory (ROM), an erasable programmable read-only memory (EPROM or flash memory), an optical fiber, a portable compact disc read-only memory (CD-ROM), an optical storage device, a magnetic storage device, or any suitable combination of the foregoing. In the context of this document, a computer readable storage medium may be any tangible medium that can contain, or store a program for use by or in connection with an instruction execution system, apparatus, or device. In the present invention, however, the computer-readable signal medium may include a data signal propagated in baseband or as part of a carrier wave, with the computer-readable program code embodied therein. Such a propagated data signal may take any of a variety of forms, including, but not limited to, electro-magnetic, optical, or any suitable combination of the foregoing. A computer readable signal medium may also be any computer readable medium that is not a computer readable storage medium and that can communicate, propagate, or transport a program for use by or in connection with an instruction execution system, apparatus, or device. Program code embodied on a computer readable medium may be transmitted using any appropriate medium, including but not limited to: wireless, wire, fiber optic cable, RF, etc., or any suitable combination of the foregoing.

The flowcharts and block diagrams in the figures illustrate the architecture, functionality, and operation of possible implementations of systems, methods and computer program products according to various embodiments of the present invention. In this regard, each block in the flowchart or block diagrams may represent a module, segment, or portion of code, which comprises one or more executable instructions for implementing the specified logical function(s). It should also be noted that, in some alternative implementations, the functions noted in the block may occur out of the order noted in the figures. For example, two blocks shown in succession may, in fact, be executed substantially concurrently, or the blocks may sometimes be executed in the reverse order, depending upon the functionality involved. It will also be noted that each block of the block diagrams or flowchart illustration, and combinations of blocks in the block diagrams or flowchart illustration, can be implemented by special purpose hardware-based systems which perform the specified functions or acts, or combinations of special purpose hardware and computer instructions.

The modules involved in the embodiments of the present invention may be implemented in software or in hardware. The described modules may also be provided in a processor, for example, as: a processor includes an parsing module, a loading module, and a registration module. The names of these modules do not in some cases limit the module itself, and for example, a parsing module may also be described as a "module that parses an interface configuration file to obtain interface configuration information".

As another aspect, the present invention also provides a computer-readable medium that may be contained in the apparatus described in the above embodiments; or may be present alone without being fitted into the device. The computer-readable medium carries one or more programs which, when executed by one of the devices, cause the device to perform the following: analyzing the interface configuration file to obtain interface configuration information; loading the implementation class of the interface according to the interface configuration information, and creating an interface executor based on the implementation class of the interface; determining an interface unique identifier, and correspondingly storing the interface unique identifier and the interface executor to finish the registration of an interface; alternatively, when the one or more programs are executed by one of the devices, the device is caused to perform the following procedures: responding to an interface call request of a user side, and analyzing request parameters in the interface call request; the request parameters include: an interface unique identifier; inquiring registered interface information to obtain an interface executor corresponding to the unique interface identifier; and calling the interface executor and sending an execution result of the interface executor to the user side.

According to the technical scheme provided by the embodiment of the invention, the complexity of interface research and development can be greatly simplified, the technical threshold of interface research and development is reduced, and the research and development efficiency of the interface is improved. As the publishing, the management and the maintenance aiming at the granularity of the interfaces are realized, the functions of other interfaces are not affected by the newly added modification change of the interfaces, and the coupling degree between the interfaces is reduced.

The above embodiments do not limit the scope of the present invention. It will be apparent to those skilled in the art that various modifications, combinations, sub-combinations and alternatives can occur depending upon design requirements and other factors. Any modifications, equivalent substitutions and improvements made within the spirit and principles of the present invention should be included in the scope of the present invention.

Claims

1. An interface registration method, the method comprising:

analyzing the interface configuration file to obtain interface configuration information;

loading the implementation class of the interface according to the interface configuration information, and creating an interface executor based on the implementation class of the interface;

and determining an interface unique identifier, and correspondingly storing the interface unique identifier and the interface executor to finish the registration of the interface.

2. The method according to claim 1, wherein the method further comprises:

creating a custom class loader to execute the step of loading the implementation class of the interface according to the interface configuration information through the custom class loader.

3. The method of claim 1, wherein the interface profile comprises: a main library file configuration item, which is used for configuring a main library file used by the current interface file; a reference interface file configuration item for configuring other interface files referenced by the current interface file; and an executable file configuration item for configuring an executable file of the current interface file;

the interface configuration file further includes: the interface realization class packet path configuration item is used for configuring a packet file path where the interface realization class is located under the condition that the interface is defined in an annotating mode; and/or an interface realization class basic information configuration item, which is used for configuring basic information of the interface realization class under the condition that the interface is defined by a configuration mode; wherein, the basic information of the interface implementation class comprises: the class name of the interface implementation class, and the method name used.

4. The method of claim 3, wherein the custom class loader comprises:

The first class loader is used for loading the package files under all paths configured under the configuration items of the main library file; the second class loader is inherited to the first class loader and is used for loading the package files under all paths configured under the reference interface file configuration items; and the third class loader is inherited to the second class loader and is used for loading the package files under all paths configured under the executable file configuration items.

5. The method of claim 4, wherein loading the implementation class of the interface according to the interface configuration information comprises:

invoking a third class loader to load the package files under all paths configured under the executable file configuration items; under the condition that the interface realization class packet path configuration item is not empty, scanning all class files under a packet file path configured by the interface realization class packet path configuration item to load the class files with notes; and under the condition that the interface implementation class basic information configuration item is not empty, loading the implementation class of the interface according to the basic information of the interface implementation class designated by the interface implementation class basic information configuration item.

6. The method of claim 1, wherein the interface is uniquely identified as a request route for the interface; the storing the unique interface identifier and the interface executor correspondingly comprises the following steps:

Adding the request route of the interface to a route tree; the route corresponding to the request route in the route tree comprises one or more nodes, and each node is used for storing the route parameters of the corresponding level contained in the request route; and storing corresponding interface executors at the final nodes of the paths corresponding to the request routes of the interfaces.

7. An interface execution method, the method comprising:

responding to an interface call request of a user side, and analyzing request parameters in the interface call request; the request parameters include: an interface unique identifier;

inquiring registered interface information to obtain an interface executor corresponding to the unique interface identifier;

and calling the interface executor and sending an execution result of the interface executor to the user side.

8. The method of claim 7, wherein the interface is uniquely identified as a request route for the interface; the registered interface information is stored in the form of a routing tree;

the querying the registered interface information to obtain the interface executor corresponding to the unique interface identifier comprises:

splitting the request route of the interface into a plurality of levels of route parameters to obtain an array formed by the plurality of levels of route parameters; performing path retrieval in the routing tree according to the array; and under the condition that the path corresponding to the request route is retrieved, acquiring an interface executor corresponding to the request type of the interface call request from a final node of the path.

9. The method of claim 8, wherein the method further comprises:

and searching an interface file corresponding to the request route from an interface file storage path and returning a query result to the user side under the condition that a path corresponding to the request route is not retrieved from the route tree or an interface executor corresponding to the request type of the interface call request is not obtained from the final-stage node of the path corresponding to the request route.

10. An interface registration apparatus, the apparatus comprising:

the analysis module is used for analyzing the interface configuration file to obtain interface configuration information;

the loading module is used for loading the implementation class of the interface according to the interface configuration information and creating an interface executor based on the implementation class of the interface;

and the registration module is used for determining an interface unique identifier, and correspondingly storing the interface unique identifier and the interface executor to finish the registration of the interface.

11. An interface execution apparatus, the apparatus comprising:

the analysis module is used for responding to an interface call request of the user terminal and analyzing request parameters in the interface call request; the request parameters include: an interface unique identifier;

The inquiry module is used for inquiring registered interface information to obtain an interface executor corresponding to the unique interface identifier;

and the execution module is used for calling the interface executor and sending the execution result of the interface executor to the user side.

12. An interface management system, the system comprising:

the interface registration device is used for analyzing the interface configuration file to obtain interface configuration information; the interface registration device is also used for loading the implementation class of the interface according to the interface configuration information and creating an interface executor based on the implementation class of the interface; the interface registration device is also used for determining an interface unique identifier, and correspondingly storing the interface unique identifier and the interface executor to finish the registration of the interface;

the interface executing device is used for responding to an interface calling request of the user side and analyzing request parameters in the interface calling request; the request parameters include: an interface unique identifier; the interface executing device is also used for inquiring registered interface information to obtain an interface executor corresponding to the unique interface identifier; the interface execution device is also used for calling the interface executor and sending the execution result of the interface executor to the user side.

13. An electronic device, comprising:

one or more processors;

storage means for storing one or more programs,

when executed by the one or more processors, causes the one or more processors to implement the method of any of claims 1-6, 7-9.

14. A computer readable medium, on which a computer program is stored, characterized in that the program, when being executed by a processor, implements the method according to any of claims 1-6, 7-9.