WO2021258340A1 - 发布系统、推送方法、应用设备、接收装置及服务管理设备 - Google Patents

发布系统、推送方法、应用设备、接收装置及服务管理设备 Download PDF

Info

Publication number
WO2021258340A1
WO2021258340A1 PCT/CN2020/098144 CN2020098144W WO2021258340A1 WO 2021258340 A1 WO2021258340 A1 WO 2021258340A1 CN 2020098144 W CN2020098144 W CN 2020098144W WO 2021258340 A1 WO2021258340 A1 WO 2021258340A1
Authority
WO
WIPO (PCT)
Prior art keywords
api
feature information
executable program
document
standard
Prior art date
Application number
PCT/CN2020/098144
Other languages
English (en)
French (fr)
Inventor
刘伟伟
常孝忠
Original Assignee
京东方科技集团股份有限公司
Priority date (The priority date is an assumption and is not a legal conclusion. Google has not performed a legal analysis and makes no representation as to the accuracy of the date listed.)
Filing date
Publication date
Application filed by 京东方科技集团股份有限公司 filed Critical 京东方科技集团股份有限公司
Priority to PCT/CN2020/098144 priority Critical patent/WO2021258340A1/zh
Priority to CN202080001101.4A priority patent/CN114144761A/zh
Priority to US17/293,641 priority patent/US20220308949A1/en
Publication of WO2021258340A1 publication Critical patent/WO2021258340A1/zh

Links

Images

Classifications

    • G—PHYSICS
    • G06—COMPUTING; CALCULATING OR COUNTING
    • G06F—ELECTRIC DIGITAL DATA PROCESSING
    • G06F9/00—Arrangements for program control, e.g. control units
    • G06F9/06—Arrangements for program control, e.g. control units using stored programs, i.e. using an internal store of processing equipment to receive or retain programs
    • G06F9/46—Multiprogramming arrangements
    • G06F9/54—Interprogram communication
    • G06F9/547—Remote procedure calls [RPC]; Web services
    • G—PHYSICS
    • G06—COMPUTING; CALCULATING OR COUNTING
    • G06F—ELECTRIC DIGITAL DATA PROCESSING
    • G06F8/00—Arrangements for software engineering
    • G06F8/70—Software maintenance or management
    • G06F8/73—Program documentation
    • G—PHYSICS
    • G06—COMPUTING; CALCULATING OR COUNTING
    • G06F—ELECTRIC DIGITAL DATA PROCESSING
    • G06F8/00—Arrangements for software engineering
    • G06F8/30—Creation or generation of source code
    • G06F8/36—Software reuse

Definitions

  • the present invention relates to the technical field of middle stations, in particular to an application programming interface (API, Application Programming Interface) publishing system, an API information push method, an API feature information acquisition method, an API publishing method, A computer-readable storage medium, an application device, a service management device, and a receiving device.
  • API Application Programming Interface
  • the purpose of the present disclosure is to provide an application program interface API publishing system, an API information pushing method, an API publishing method, a computer-readable storage medium, an application server, and a service management platform server.
  • an application program interface publishing system which includes a receiving device, a service management device, and at least one application device,
  • the application equipment includes:
  • a first storage module on which a first executable program is stored
  • One or more first processors can call the first executable program, so that the one or more first processors implement the following operations:
  • the receiving device includes:
  • a second storage module on which a second executable program is stored
  • One or more second processors can call the second executable program, so that the one or more second processors implement the following operations:
  • the service management equipment includes:
  • a third storage module on which a third executable program is stored
  • One or more third processors can call the third executable program, so that the one or more third processors implement the following operations:
  • the step of obtaining the standard API document performed by the receiving device includes:
  • the API feature information includes class annotations of the API, interface annotations of the API, parameter annotations of the API, parameter object annotations of the API, configuration tables of the API, and At least one of the interface addresses.
  • the first executable program is further configured to implement the following operations when the first processor invokes the first executable program:
  • the second executable program is further configured to implement the following operations when the second processor invokes the second executable program:
  • the standard API document Before parsing the standard API document, the standard API document is stored in the buffer of the receiving device.
  • the second executable program is further configured to implement the following operations when the second processor invokes the second executable program:
  • the second executable program is further configured to implement the following operations when the second processor invokes the second executable program:
  • the API feature information obtained by the receiving device is compared with the API feature information stored locally to determine whether the API corresponding to the API feature information has changed.
  • the API changes include: existing API updates or new APIs.
  • the second executable program is further configured to implement the following operations when the second processor invokes the second executable program:
  • the API feature information is stored locally in the receiving device.
  • the application program includes at least one of a short message platform, a user center, a hosting management system, and a message notification.
  • an API information push method is provided, which is applied to an application device, and the information push method includes:
  • the API feature information includes class annotations of the API, interface annotations of the API, parameter annotations of the API, parameter object annotations of the API, configuration tables of the API, and At least one of the interface addresses.
  • the pushing method further includes:
  • a method for obtaining API feature information is provided, which is applied to a receiving device, and the method for obtaining includes:
  • the obtaining method further includes:
  • the obtaining method further includes performing after obtaining API feature information:
  • the API feature information is compared with the API feature information stored locally to determine whether the API corresponding to the API feature information has changed.
  • the API changes include: existing API updates or new APIs.
  • the obtaining method further includes:
  • the API feature information is persistently stored locally.
  • the obtaining method further includes performing before parsing the standard API document:
  • an API publishing method which is applied to a service management device, and the API publishing method includes:
  • a computer-readable storage medium on which an executable program is stored, and when the executable program is invoked, any one of the following methods can be implemented:
  • an application device includes:
  • a first storage module on which a first executable program is stored
  • One or more first processors the one or more first processors can call the first executable program, so that the one or more first processors implement the second aspect of the present disclosure The said push method.
  • a receiving device includes:
  • a second storage module on which a second executable program is stored
  • One or more second processors can call the second executable program, so that the one or more second processors implement the method according to the third aspect of the present disclosure Provide the described acquisition method.
  • a service management device includes:
  • a third storage module on which a third executable program is stored
  • One or more third processors can call the third executable program, so that the one or more third processors implement the first aspect of the present disclosure API publishing method.
  • FIG. 1 is a schematic diagram of modules of an implementation manner of the API publishing system provided by the present disclosure
  • Figure 2 is a schematic diagram of a page provided by a service management device in the API publishing system provided by the present disclosure
  • FIG. 3 is a flowchart of the push method provided by the present disclosure
  • FIG. 4 is a flowchart of the acquisition method provided by the present disclosure
  • FIG. 5 is a flowchart of the publishing method provided by the present disclosure
  • FIG. 6 is a schematic diagram of interaction between application equipment and the receiving device of the service management platform server in the API publishing system provided by the present disclosure
  • Figure 7 shows a schematic diagram of a user obtaining a service through the API publishing system.
  • API Application Programming Interface
  • the purpose is to provide applications and developers with the ability to access a set of routines based on certain software or hardware without having to access the source code or understand the internal working mechanism. The details.
  • an application program interface publishing system includes a receiving apparatus 200, a service management device 300, and at least one application device 100.
  • the application device can run application programs.
  • the application device 100 includes:
  • a first storage module on which a first executable program is stored
  • One or more first processors can call the first executable program, so that the one or more first processors implement the following operations:
  • the receiving device 200 includes:
  • a second storage module on which a second executable program is stored
  • One or more second processors can call the second executable program, so that the one or more second processors implement the following operations:
  • the service management device 300 includes:
  • a third storage module on which a third executable program is stored
  • One or more third processors can call the third executable program, so that the one or more third processors implement the following operations:
  • the API publishing system includes at least one application device 100.
  • the first executable program in each application device 100 is a plug-in program.
  • the plug-in program is associated with one or more applications installed in the application device 100.
  • the program is associated.
  • the plug-in program can implement the aforementioned acquisition of API feature information, generate corresponding one or more standard API documents, and push the standard API documents for one or more applications installed in the application device 100 and associated with the plug-in program.
  • the API standard document may also include one or more API information.
  • the standard API document can be generated according to the following method:
  • the API thread is started to be generated through the startup class built in the framework of the application program itself;
  • the main thread continues to execute the startup logic, and the thread that generates the API processes the corresponding logic asynchronously;
  • the plug-in program obtains the associated interface and annotation information through the reflection logic of the application framework itself, and after a certain degree of splicing and packaging, forms an API object;
  • a JSON array is formed by combining and transforming multiple API objects, and the JSON array is the standard API document.
  • reflection logic means that in the running state, for any class, you can know all the properties and methods of this class, and for any object, you can call any of its methods.
  • the reflection mechanism of the Java language is the function of dynamically obtaining information and dynamically calling object methods.
  • the second executable program in the receiving device 200 is an automatic receiving program that can filter all received information, and filter out incomplete information and data whose format does not meet the format required by the standard API document. , Only keep standard API documentation.
  • the receiving device can parse and process the standard API document to obtain API feature information for display by the service management device 300.
  • the application device 100 can obtain the corresponding API feature information, so that the receiving device 200 can always receive the standard API document containing the latest version of the API feature information, thereby ensuring that the service management device 300 can display the latest version of the API.
  • the steps for parsing standard API documents are not particularly limited.
  • the receiving program receives the API information through the interface, it is first saved in the cache, and the interface returns the stateless symbol; through the listening thread, the cache is monitored After adding new data, parse json as an object, clear invalid data, convert input and output parameter formats, update basic service attribute information, fill in default values, compare and judge insert or update, and save it persistently to the database.
  • the application developer sends the API of the application running on the application device 100 to the service management device 300 for the user to view.
  • the service management device 300 can actively and actively send an API acquisition or update request to the application device 100 at any time, and scan the relevant application code through swagger to obtain relevant API document information, which brings the risk of code intrusion.
  • the application device 100 actively pushes API standard documents carrying API feature information to the receiving device 200, which reduces or even eliminates the risk of code intrusion into the application device 100 and data tampering in the application device 100, and improves the application device 100 Security.
  • the receiving device 200 including the second executable program (ie, the automatic receiving program) is designed to operate independently of the application device 100 and the service management device 300 after receiving the standard API document, and will not affect The operation of the application program in the application device 100 will not affect the operation of the service management device 300 either.
  • the receiving apparatus 200 and the service management device 300 may be arranged at the same end of the network.
  • the first executable program ie, plug-in program
  • the application device 100 may be used to obtain API feature information, generate a standard API document according to the API feature information, and push the standard API document to The receiving device and the like operate.
  • the plug-in program is triggered, and the API feature information is collected through the reflection mechanism, and the API feature information is sorted and coded , To form the standard API document.
  • the plug-in program only pushes the standard API document once when the application is started. That is, after the standard API document is pushed to the receiving device 200, the collection and acquisition of the API feature information is stopped.
  • the plug-in is only triggered once when the application is started, the risk of software like swagger intruding into the application code to obtain API feature information at will during the use of the application is avoided.
  • a second executable program ie, a receiving program
  • the receiving device 200 for performing the above-mentioned "screening of the received information to obtain the standard API document; parsing the standard API document to obtain the API feature) Information; the step of obtaining API feature information according to the API feature information.
  • the API of the receiving program is called to push the standard API document to the interface of the receiving program.
  • the specific content of the API feature information is not particularly limited, as long as the user can display the API feature information in the service management device 300 and the API acquisition address can call the corresponding application.
  • the API feature information includes class annotations of the API, interface annotations of the API, parameter annotations of the API, parameter object annotations of the API, configuration tables of the API, At least one of the interface addresses of the API.
  • the class annotation includes at least one of the publisher information, the domain to which the API belongs, and the category to which the API belongs.
  • the specific content of the interface annotation is not particularly limited.
  • the interface annotation may include the name information of the API, the service description information of the API, the internal and external attributes of the API, and the current limiting attribute of the API. , At least one of the public API information of the API.
  • the content of the parameter annotation is not particularly limited.
  • the parameter annotation includes at least one of the parameter name, parameter description, parameter default value, parameter instance value, whether the attribute must be input, and the parameter type. One.
  • the specific content of the parameter object annotation is not particularly limited.
  • the parameter object annotation includes parameter path, parameter name, parameter description, parameter default value, parameter example value, parameter type, whether At least one of attribute and access protocol type must be entered.
  • Restful interface parameters are only service interface information and parameter information.
  • a set of API document generation specifications is customized, including the above-mentioned API feature information, to ensure service attributes.
  • the service management device 300 performs unified classification and management of multiple APIs on the service management device 300 according to the above API information. On the one hand, it is convenient for other users to view on the platform, and on the other hand, it can set permissions for the corresponding field. Only users can subscribe to or call related APIs.
  • the service management device 300 may restrict the identity and authority of the subscriber through the publisher information, the domain described by the API, and the category described by the API. For example, when the publisher information of the API indicates that the publisher is a financial person, the service management device 300 will only allow financial-related users to subscribe to the corresponding API. When the domain mentioned by the API is the personnel management domain, the service management device 300 will only allow personnel-related users to subscribe to the corresponding API.
  • the service management platform can set whether the corresponding API document is exposed to the outside through internal and external attributes or public API information.
  • the application on the application device has a shared attribute, that is, the application will be called in multiple systems, such as SMS platform, user center, message notification, etc., by publishing the corresponding API of the shared application
  • other users can directly call the application through API related information on the service management device 300 when designing an application program or system, without repeated development.
  • Unstable network conditions and unstable conditions of the receiving device 200 may cause the receiving device 200 to fail to obtain API information.
  • the first executable program that is, the plug-in program
  • the plug-in program installed in the application device 100 will receive the sending failure information.
  • the application program publisher uses the application program publisher to perform corresponding error troubleshooting and other processing.
  • the plug-in program of the application device 100 provides a non-inductive service. Regardless of whether the standard API document is successfully pushed or not, it can provide a stable application service without any impact on the normal operation of the application.
  • the first executable program of the receiving apparatus 200 runs independently of the system of the service management device 300, and is configured with high reliability. After receiving the API document information, the receiving device 200 will immediately save the API document information in a cache, such as a redis database. During subsequent operations such as parsing, even if the receiving device 200 has system instability and other conditions that cause the loss of API document information, the corresponding API document information can be found in the cache without requesting the application device to send it.
  • a cache such as a redis database
  • the parameters that need to be displayed may be more than the parameters that the receiving device 200 parses and obtains from the standard API document.
  • the service management device 300 parses the obtained API feature information Directly displayed as API feature information.
  • the receiving apparatus 200 further supplements the API feature information obtained by parsing with default values.
  • the service management device 300 displays API feature information supplemented with default values. It can be understood that the API feature information may be the information in the directly parsed API document, or it may be the API document information that has been parsed and supplemented with default values.
  • the default value supplemented by the receiving device 200 is not particularly limited.
  • the default value may be a current limiting attribute or the like.
  • the default value can be set according to the domain of the application program corresponding to the API and the unique identifier of the application program.
  • the default value of the current-limiting attribute may be "unlimited current" for APIs corresponding to certain applications.
  • the receiving device 200 is also used to determine whether the API has changed.
  • the second executable program of the receiving device 200 is further configured to implement the following operations when the second processor calls the second executable program: according to the API feature information and the API stored locally The feature information is compared to determine whether the API corresponding to the API feature information has changed.
  • the API changes include both existing API updates and new APIs.
  • the application device 100 can publish a new API through the plug-in program, or update the API through the plug-in program.
  • the second executable program of the receiving apparatus 200 is further configured to implement the following operations when the second processor invokes the second executable program:
  • the API feature information is compared with the API feature information stored locally to determine whether the API corresponding to the API feature information has changed.
  • each API corresponds to a service name
  • the receiving device 200 can compare the API service name in the extracted API feature information with the locally stored API service name. When the extracted API feature information is not stored locally If the API service name is selected, the API corresponding to the name is determined to be a new API.
  • the receiving device 200 is also used to compare the API feature information stored locally by the receiving device 200 with the received API feature information when determining that the received API feature information is feature information of an existing API, and compare When the results are inconsistent, it is determined that an existing API update has occurred, and the updated API feature information is integrated with the unupdated API information.
  • the receiving device may store the received standard API document in the cache of the receiving device 200.
  • the API feature information can be persistently stored in the local of the receiving device 200, such as a mysql database.
  • the service management device 300 not only has the functions of serving as the data source of the API gateway, displaying the feature information of the API, and obtaining the address, etc., but also can provide the function of webpage debugging API. Specifically, the service manager is configured to test the corresponding API according to the API debugging instruction.
  • the service management device 300 is also used for authentication of multiple subsequent API gateway calls. Specifically, the service management device 300 is also configured to, according to the API call instruction, respond to the API call instruction. The gateway performs authentication. Only when the API gateway passes the authentication, the API gateway is allowed to call the corresponding API.
  • the service management device 300 can display the API information and the acquisition address of the API.
  • the content displayed by the service management device 300 will be described in detail below with reference to FIG. 2.
  • Figure 2 involves related information about the API of the cloud SMS application.
  • the service management device 300 provides a display page that displays the information of the API interface corresponding to the application cloud short message and the related information of the cloud short message.
  • the content displayed on the page includes six parts, namely:
  • the basic information of the "cloud SMS” application includes: service description (ie, SMS platform), category (ie, SMS reminder), service number (ie, 30214), service provision (ie, xxx SMS platform), Public annoyance (ie, no), release date (ie, yy-mm-dd), version number (ie, 1.0.0), maximum number of calls per second (ie, 1000), maximum number of calls per hour (ie, 3600000);
  • Service business owner information including: contact name, contact person number, contact email, and contact phone.
  • Service technology owner information including: contact name, contact person number, contact email, and contact phone.
  • API service information including: service English name, API interface address, internal and external API (that is, whether this API is an internal API or an external API, for cloud SMS applications, the API is an external API), authorization method (ie, ak/ sk authentication method), service category (ie, API service), access protocol type (ie, restful), method type (ie, GET), and request format (ie, HTTP).
  • authorization method ie, ak/ sk authentication method
  • service category ie, API service
  • access protocol type ie, restful
  • method type ie, GET
  • request format ie, HTTP
  • Historical version including the version number, the time of change, and the entry to view the historical version.
  • Cloud SMS status review the number of subscribers (ie, 8); the cumulative number of calls (ie, 123456789).
  • the subscription entry, service debugging entry, and service export entry are also provided on the above-mentioned display page.
  • the user can debug the API through the service debugging entry on the page, the user can export the standard API document through the service export entry, and the user can also subscribe to the API through the subscription entry.
  • the service management device 300 may also support a fuzzy search function in the visualized page, so that the user can obtain the required service in the service management device 300 and reduce the workload of the docking personnel.
  • the service management device 300 stores APIs of two applications, “cloud SMS” and “bulk SMS”, which are used to search for "SMS" on the visual interface provided by the service management device 300, and the search results may include “cloud Two retrieval results of "SMS” and "SMS”.
  • the service management device 300 can provide management of service relationships and subscription relationships.
  • the first executable that can perform the steps of "acquire API feature information in response to the start signal of the application program; generate a standard API document according to the API feature information; push the standard API document to the receiving device” and other steps
  • a program ie, a plug-in program
  • a program is introduced into the application device 100 to obtain various API feature information defined by the application program in the API class.
  • a standard API document is generated, the API of the second executable program (ie, the receiving program) installed on the receiving device 200 is called, and a push event is triggered to push the standard API document to the receiving device 200 .
  • the receiving device 200 parses the standard API document to obtain API feature information by calling the second executable program, and supplements the API feature information obtained by parsing with default values.
  • the API feature information obtained by the receiving device 200 is compared with the information stored locally to determine whether an API change occurs, and the API information is stored locally in the receiving device 200. While storing the API information locally, the receiving device 200 pushes the API information to the service management device 300 for the service management device to visually display in the form of a service market.
  • the user wants to publish the application API on the service market, first download the relevant plug-in (ie, the first executable program) to the user’s system server (application device 100), and trigger when the application starts
  • the plug-in event forms a standard API document, which is sent to the receiving device installed with the receiving program (ie, the second executable program), and is processed by the receiving program and then published to the service market for other users to view and call.
  • the user can also view API documents provided by other users in the service market, and perform related operations such as invoking.
  • the user can also manually fill in the standard API document template provided by the service market and send it to the service market to realize the release of the API.
  • the application device can be a user's server terminal, and the service management platform is also a server terminal, and both can be a cloud system.
  • an API information push method is provided.
  • the information push method is applied to the application device 100.
  • the information push method includes:
  • step S110 in response to the start signal of the application program, the API feature information is acquired
  • step S120 a standard API document is generated according to the API feature information
  • step S130 the standard API document is pushed to the receiving device.
  • the API feature information includes class annotations of the API, interface annotations of the API, parameter annotations of the API, parameter object annotations of the API, configuration tables of the API, and At least one of the interface addresses.
  • the standard API document carrying the API feature information of the application can be actively pushed to the receiving device 200, and the feature information of the latest version of the API can be provided to the service management device 300 through the receiving device 200, As a result, the service management device 300 can always display the latest version of the API, reducing or even eliminating the risk of code intrusion into the application device 100 and data tampering in the application device 100, and improving the security of the application device 100.
  • the information pushing method can be implemented by a plug-in installed in the application device 100.
  • the API feature information is defined by the application installed on the application device 100, when the application is started, a plug-in event will be triggered.
  • the API feature information is collected, sorted, and coded to form a standard API document, and the The standard API document is pushed to the receiving device.
  • an automatic receiving program i.e., the second executable program described above
  • the receiving device to realize automatic receiving of API documents.
  • the pushing method may further include:
  • step S140 after the standard API document is pushed to the receiving device, the acquisition of the API feature information is stopped.
  • the pushing method may further include:
  • step S150 in response to the push failure information and the application restart signal, resend the standard API document to the receiving device.
  • a method for acquiring API feature information is provided, which is applied to the receiving device 200. As shown in FIG. 3, the method for acquiring includes:
  • step S210 filter the received information to obtain the standard API document
  • step S220 the standard API document is parsed to obtain the API feature information.
  • the acquisition method provided by the present disclosure is executed by the receiving device 200.
  • the receiving device 200 executes the above steps S210 and S220 independently of the application device 100 and the service management device 300, and will not affect the application device 100.
  • the operation of the application program will not affect the operation of the service management device 300.
  • the obtaining method may further include:
  • step S230 the API feature information obtained by parsing is supplemented with default values.
  • the default value may be a current limiting attribute or the like.
  • the acquiring method further includes performing after step S220:
  • step S240 a comparison is made between the API feature information and the API feature information stored locally to determine whether the API corresponding to the API feature information has changed.
  • the API changes include both existing API updates and new APIs.
  • the application device 100 can publish a new API through the plug-in program, and can also update the API through the plug-in program.
  • the receiving device 200 is further configured to compare the API feature information with the API feature information stored locally to determine whether the API corresponding to the API feature information has changed.
  • each API corresponds to a service name
  • the receiving device 200 can compare the API service name in the extracted API feature information with the locally stored API service name. When the extracted API feature information is not stored locally If the API service name is selected, the API corresponding to the name is determined to be a new API.
  • the obtaining method further includes:
  • step S250 the API feature information is persistently stored locally.
  • the obtaining method includes:
  • step S260 when receiving the standard API document fails, the standard API document is stored locally.
  • the obtaining method further includes performing before parsing the standard API document:
  • an API publishing method is provided.
  • the API publishing method is executed by the service management apparatus 300.
  • the API publishing method includes:
  • step S310 receiving API feature information obtained by analysis by the receiving device
  • step S320 the API feature information is displayed.
  • the service management device 300 visually displays the API through the above-mentioned method, which can be viewed and subscribed to by all users.
  • the API publishing method further includes:
  • step S330 the gateway that issued the API call instruction is authenticated according to the API call instruction;
  • step S340 the corresponding API is debugged according to the API debugging instruction.
  • a computer-readable storage medium on which an executable program is stored, and when the executable program is invoked, any one of the following methods can be implemented:
  • Such software may be distributed on a computer-readable medium, and the computer-readable medium may include a computer storage medium (or a non-transitory medium) and a communication medium (or a transitory medium).
  • the term computer storage medium includes volatile and non-volatile implementations in any method or technology for storing information (such as computer-readable instructions, data structures, program modules, or other data). Sexual, removable and non-removable media.
  • Computer storage media include but are not limited to RAM, ROM, EEPROM, flash memory or other memory technologies, CD-ROM, digital versatile disk (DVD) or other optical disk storage, magnetic cassettes, magnetic tapes, magnetic disk storage or other magnetic storage devices, or Any other medium used to store desired information and that can be accessed by a computer.
  • a communication medium usually contains computer-readable instructions, data structures, program modules, or other data in a modulated data signal such as a carrier wave or other transmission mechanism, and may include any information delivery medium. .
  • an application device is provided, and the application server includes:
  • a first storage module on which a first executable program is stored
  • One or more first processors the one or more first processors can call the first executable program, so that the one or more first processors implement the second aspect of the present disclosure The push method.
  • the application device may also include one or more I/O first interfaces, connected between the first processor and the first storage module, and configured to implement information between the first processor and the first storage module Interactive.
  • the first processor is a device with data processing capabilities, including but not limited to a central processing unit (CPU), etc.; the first storage module is a device with data storage capabilities, including but not limited to random access memory (RAM, more Specifically, such as SDRAM, DDR, etc.), read-only memory (ROM), charged erasable programmable read-only memory (EEPROM), flash memory (FLASH).
  • RAM random access memory
  • ROM read-only memory
  • EEPROM charged erasable programmable read-only memory
  • FLASH flash memory
  • the first I/O interface is connected between the first processor and the first storage module, and can realize the information interaction between the first processor and the first storage module, which includes but is not limited to a data bus (Bus) and the like.
  • a data bus Bus
  • the first processor, the first storage module, and the first I/O interface are connected to each other through a bus, and further connected to other components of the display terminal.
  • a receiving device includes:
  • a second storage module on which a second executable program is stored
  • One or more second processors can call the second executable program, so that the one or more second processors implement the method according to the third aspect of the present disclosure Provided access method.
  • the receiving device may also include one or more I/O second interfaces, connected between the second processor and the second storage module, and configured to implement information between the second processor and the second storage module Interactive.
  • the second processor is a device with data processing capabilities, including but not limited to a central processing unit (CPU), etc.
  • the first storage module is a device with data storage capabilities, including but not limited to random access memory (RAM, more Specifically, such as SDRAM, DDR, etc.), read-only memory (ROM), charged erasable programmable read-only memory (EEPROM), flash memory (FLASH).
  • RAM random access memory
  • ROM read-only memory
  • EEPROM charged erasable programmable read-only memory
  • FLASH flash memory
  • the second I/O interface is connected between the second processor and the second storage module, and can realize the information interaction between the second processor and the second storage module, which includes but is not limited to a data bus (Bus) and the like.
  • a data bus Bus
  • the second processor, the second storage module, and the second I/O interface are connected to each other through a bus, and further connected to other components of the display terminal.
  • a service management device includes:
  • a third storage module on which a third executable program is stored
  • One or more third processors can call the third executable program, so that the one or more third processors implement the fourth The API publishing method provided by the aspect.
  • the service management device may also include one or more I/O second interfaces, connected between the third processor and the third storage module, and configured to realize the connection between the third processor and the third storage module. Information exchange.
  • the third processor is a device with data processing capabilities, including but not limited to a central processing unit (CPU), etc.; the first storage module is a device with data storage capabilities, including but not limited to random access memory (RAM, more Specifically, such as SDRAM, DDR, etc.), read-only memory (ROM), charged erasable programmable read-only memory (EEPROM), flash memory (FLASH).
  • RAM random access memory
  • ROM read-only memory
  • EEPROM charged erasable programmable read-only memory
  • FLASH flash memory
  • the third I/O interface is connected between the third processor and the third storage module, and can realize the information interaction between the third processor and the third storage module, which includes but is not limited to a data bus (Bus) and the like.
  • a data bus Bus
  • the third processor, the third storage module, and the third I/O interface are connected to each other through a bus, and further connected to other components of the display terminal.

Landscapes

  • Engineering & Computer Science (AREA)
  • Theoretical Computer Science (AREA)
  • Software Systems (AREA)
  • General Engineering & Computer Science (AREA)
  • Physics & Mathematics (AREA)
  • General Physics & Mathematics (AREA)
  • Library & Information Science (AREA)
  • Stored Programmes (AREA)

Abstract

本公开提供一种应用程序接口API发布系统，应用设备包括：第一存储模块，其上存储有第一可执行程序；第一处理器能够调用第一可执行程序，以实现以下操作：获取应用程序的API特征信息；根据API特征信息生成标准API文档；将标准API文档推送至接收装置；接收装置包括：第二存储模块，其上存储有第二可执行程序；第二处理器能够调用第二可执行程序，以实现以下操作：获取标准API文档；解析标准API文档；服务管理设备包括：第三存储模块，其上存储有第三可执行程序；第三处理器实现以下操作：展示接收API特征信息。本公开还提供API的信息推送方法、API信息的获取方法、API发布方法、计算机可读存储介质、应用设备、接收装置、服务管理设备。

Description

发布系统、推送方法、应用设备、接收装置及服务管理设备 技术领域
本发明涉及中台技术领域，具体地，涉及一种应用程序接口(API，Application Programming Interface)发布系统、一种API的信息推送方法、一种API特征信息的获取方法、一种API发布方法、一种计算机可读存储介质、一种应用设备、一种服务管理设备和一种接收装置。
背景技术
中台系统建设中，需要将应用例如短信平台、用户中心、宿管系统、消息通知等有共享属性的API服务发布至服务治理平台，展示给用户查看，方便用户在各自的系统开发中调用，降低重复开发的成本，提高共享API服务的利用率。
发明内容
本公开的目的在于提供一种应用程序接口API发布系统、一种API的信息推送方法、一种API发布方法、一种计算机可读存储介质、一种应用服务器和一种服务管理平台服务器。
作为本公开的一个方面，提供一种应用程序接口发布系统，包括接收装置、服务管理设备和至少一个应用设备，
所述应用设备包括：
第一存储模块，其上存储有第一可执行程序；
一个或多个第一处理器，所述一个或多个第一处理器能够调用所述第一可执行程序，以使得所述一个或多个第一处理器实现以下操作：
响应于应用程序的启动信号，获取所述应用程序的API特征信息；
根据所述API特征信息生成标准API文档；
将所述标准API文档推送至所述接收装置；
所述接收装置包括：
第二存储模块，其上存储有第二可执行程序；
一个或多个第二处理器，所述一个或多个第二处理器能够调用所述第二可执行程序，以使得所述一个或多个第二处理器实现以下操作：
获取所述标准API文档；
解析所述标准API文档，以获得所述API特征信息；
所述服务管理设备包括：
第三存储模块，其上存储有第三可执行程序；
一个或多个第三处理器，所述一个或多个第三处理器能够调用所述第三可执行程序，以使得所述一个或多个第三处理器实现以下操作：
接收并展示所述接收装置解析获得的API特征信息。
可选地，所述接收装置执行的获取所述标准API文档的步骤包括：
对所述接收装置接收到的信息进行筛选，以获得所述标准API文档。
可选地，所述API特征信息包括所述API的类注解、所述API的接口注解、所述API的参数注解、所述API的参数对象注解、所述API的配置表、所述API的接口地址中的至少一者。
可选地，所述第一可执行程序还被配置为当所述第一处理器调用所述第一可执行程序时，实现以下操作：
将所述标准API文档推送至所述接收装置后停止获取所述API特征信息。
可选地，所述第二可执行程序还被配置为当所述第二处理器调用所述第二可执行程序时实现以下操作：
解析所述标准API文档之前，将所述标准API文档存储在所述接收装置的缓存中。
可选地，所述第二可执行程序还被配置为当所述第二处理器调用所述第二可执行程序时实现以下操作：
对解析获得的所述API特征信息补充默认值。
可选地，所述第二可执行程序还被配置为当所述第二处理器调用所述第二可执行程序时实现以下操作：
根据所述接收装置获得的API特征信息与存储在本地的API特征信息进行对比，以判断所述API特征信息对应的API是否发生变动。
可选地，所述API变动包括：已有API更新或新增API。
可选地，所述第二可执行程序还被配置为当所述第二处理器调用所述第二可执行程序时实现以下操作：
将所述API特征信息保存在所述接收装置本地。
可选地，所述应用程序包括短信平台、用户中心、宿管系统、消息通知中的至少一种。
作为本公开的第二个方面，提供一种API的信息推送方法，应用于应用设备，所述信息推送方法包括：
响应于应用程序程序的启动信号，获取所述应用程序的API特征信息；
根据所述API特征信息生成标准API文档；
将所述标准API文档推送至接收装置。
可选地，所述API特征信息包括所述API的类注解、所述API的接口注解、所述API的参数注解、所述API的参数对象注解、所述API的配置表、所述API的接口地址中的至少一者。
可选地，所述推送方法还包括：
将所述标准API文档推送至所述接收装置后停止获取所述API特征信息。
作为本公开的第三个方面，提供一种API特征信息的获取方法，应用于接收装置，所述获取方法包括：
对接收到的信息筛选以获取所述标准API文档；
解析所述标准API文档，以获得所述API特征信息。
可选地，所述获取方法还包括：
对解析获得的所述API特征信息补充默认值。
可选地，所述获取方法还包括在获得API特征信息后进行的：
根据所述API特征信息与存储在本地的API特征信息进行对比，以判断所述API特征信息对应的API是否发生变动。
可选地，所述API变动包括：已有API更新或新增API。
可选地，所述获取方法还包括：
将所述API特征信息持久化保存在本地。
可选地，所述获取方法还包括在解析所述标准API文档之前进行的：
将所述标准API文档保存在缓存中。
作为本公开的第四个方面，提供一种API发布方法，应用于服务管理设备，所述API发布方法包括：
接收所述接收装置解析获得的API特征信息，其中，所述API特征信息由所述获取方法所得到；
展示所述API特征信息。
作为本公开的第五个方面，提供一种计算机可读存储介质，其上存储有可执行程序，当所述可执行程序被调用时能够实现以下方法中的任意一者：
本公开第二个方面所提供的推送方法；
本公开第三个方面所提供的获取方法；
本公开第四个方面所提供的API发布方法。
作为本公开的第六个方面，提供一种应用设备，所述应用设备包括：
第一存储模块，其上存储有第一可执行程序；
一个或多个第一处理器，所述一个或多个第一处理器能够调用所述第一可执行程序，以使得所述一个或多个第一处理器实现本公开第二个方面所提供的所述的推送方法。
作为本公开的第七个方面，提供一种接收装置，所述接收装置包括：
第二存储模块，其上存储有第二可执行程序；
一个或多个第二处理器，所述一个或多个第二处理器能够调用所述第二可执行程序，以使得所述一个或多个第二处理器实现根据本公开第三个方面所提供的所述的获取方法。
作为本公开的第八个方面，提供一种服务管理设备，所述服务管理设备包括：
第三存储模块，其上存储有第三可执行程序；
一个或多个第三处理器，所述一个或多个第三处理器能够调用所述第三可执行程序，以使得所述一个或多个第三处理器实现本公开第一个方面所提供的API发布方法。
附图说明
附图是用来提供对本公开的进一步理解，并且构成说明书的一部分，与下面的具体实施方式一起用于解释本公开，但并不构成对本公开的限制。在附图中：
图1是本公开所提供的API发布系统的一种实施方式的模块示意图；
图2是本公开所提供的API发布系统中服务管理设备提供的页面的示意图；
图3是本公开所提供的推送方法的流程图；
图4是本公开所提供的获取方法的流程图；
图5是本公开所提供的发布方法的流程图；
图6是本公开所提供的API发布系统中，应用设备与服务管理平台服务器接收装置的交互示意图；
图7所示的是用户通过所述API发布系统获取服务的示意图。
具体实施方式
以下结合附图对本公开的具体实施方式进行详细说明。应当理解的是，此处所描述的具体实施方式仅用于说明和解释本公开，并不用于限制本公开。
API(Application Programming Interface，应用程序接口)是一些预先定义的函数，目的是提供应用程序与开发人员基于某软件或硬件得以访问一组例程的能力，而又无需访问源码，或理解内部工作机制的细节。
作为本公开的第一个方面，提供一种应用程序接口发布系统，如图1所示，该API发布系统包括接收装置200、服务管理设备300和至少一个应用设备100。
应用设备可以运行应用程序，在本公开中，应用设备100包括：
第一存储模块，其上存储有第一可执行程序；
一个或多个第一处理器，所述一个或多个第一处理器能够调用所述第一可执行程序，以使得所述一个或多个第一处理器实现以下操作：
响应于应用程序程序的启动信号，获取所述应用程序的API特征信息；
根据所述API特征信息生成标准API文档；
将所述标准API文档推送至所述接收装置。
接收装置200包括：
第二存储模块，其上存储有第二可执行程序；
一个或多个第二处理器，所述一个或多个第二处理器能够调用所述第二可执行程序，以使得所述一个或多个第二处理器实现以下操作：
获取所述标准API文档；
解析所述标准API文档，以获得所述API特征信息。
服务管理设备300包括：
第三存储模块，其上存储有第三可执行程序；
一个或多个第三处理器，所述一个或多个第三处理器能够调用所述第三可执行程序，以使得所述一个或多个第三处理器实现以下操作：
展示所述API特征信息。
本公开所提供的API发布系统包括至少一个应用设备100，每个应用设备100中第一可执行程序是一种插件程序，将所述插件程序与安装在应用设备100中的一个或多个应用程序进行关联。该插件程序可对安装在应用设备100中的、与所述插件程序关联的一个或多应用程序以实现上述获取API特征信息、生成对应的一个或多个标准API文档、推送所述标准API文档至接收装置200的操作。并且，API标准文档中也可以包括一个或多个API信息。
在本公开中，对如何生成标准API标准文档不做特殊的限定。
作为一种可选实施方式，可以按照以下方法生成所述标准API文档：
当与所述插件程序关联的应用程序启动时，通过应用程序的框架本身内置的启动类，启动生成API线程；
主线程继续执行启动逻辑，生成API的线程异步处理相应逻辑；
插件程序通过应用程序的框架本身的反射逻辑，将关联的接口和注解信息获取出来，并经过一定程度的拼接封装，形成API对象；
通过对多各API对象组合转换，形成JSON数组，该JSON数组即为所述标准API文档。
需要指出的是，反射逻辑指在运行状态中，对于任意一个类，都能够知道这个类的所有属性和方法，对于任意一个对象，都能调用它的任意一个方法。Java语言的反射机制为动态获取信息，以及动态调用对象方法的功能。
接收装置200中的第二可执行程序是一种自动接收程序，可以对接收到的所有信息进行筛选，筛除不完整的信息、以及格式不满足标准API文档所要求的格式的数据进行筛除，只保留标准API文档。并且，接收装置可以对标准API文档进行解析处理，得到API特征信息，以供服务管理设备300进行展示。
在本公开中，只要应用程序启动，应用设备100即可获取到相应的API特征信息，从而使得接收装置200总是能够接收到包含最新版本API特征信息的标准API文档，从而可以保证服务管理设备300能够展示最新版本的API。
在本公开中，对解析标准API文档的步骤不做特殊限定，可选地，接收程序通过接口接收到API信息后，首先保存至缓存中，接口返回无状态符号；通过监听线程，监听到缓存中新增数据后，解析json为对象，清除无效数据，转换出入参数格式，更新服务基本属性信息，填充默认值，对比判断插入或者更新，持久化保存至数据库。
应用开发商将运行在应用设备100上的应用的API发送至服务管理设备300中，以供用户查看。在相关技术中(如swagger)，服务管理设备300可以随时且主动向应用设备100发送API获取或更新请求，通过swagger扫描相关应用程序代码从而获取相关API文档信息，带来了代码入侵的风险。在本公开中，应用设备100主动向接收装置200推送携带有API特征信息的API标准文档，降低甚至消除了代码入侵应用设备100、以及应用设备100中数据被篡改的风险，提高了应用设备100的安全性。
并且，在本公开中，设计了包括第二可执行程序(即，自动接收程序)的接收装置200来接收到标准API文档后，独立于应用设备100和服务管理设备300运行，既不会影响应用设备100中应用程序的运行，也不会影响服务管理设备300的运行。
为了便于维护，作为一种可选实施方式，可以将接收装置200和服务管 理设备300设置在网络中的同一端。
在本公开中，可以由设置在应用设备100上的第一可执行程序(即，插件程序)实现获取API特征信息、根据所述API特征信息生成标准API文档、将所述标准API文档推送至所述接收装置等操作。首先，应用程序完成对该应用程序的API特征信息的定义后，在启动所述应用程序时，会触发所述插件程序，通过反射机制，收集API特征信息，并对API特征信息进行整理、编码，形成所述标准API文档。
上文中已经介绍了生成标准API文档的方式，这里不再赘述。
作为一种可选实施方式，该插件程序只在应用程序启动时推送一次标准API文档。也就是说，在所述标准API文档被推送至接收装置200后，停止收集、获取所述API特征信息。相应地，由于该插件只在应用程序启动时触发一次，避免了类似swagger的软件在应用程序使用过程中随意侵入应用程序代码中获取API特征信息的风险。
在本公开中，对如何将所述标准API文档推送至接收装置200不做特殊的限定。接收装置200中安装有第二可执行程序(即，接收程序)，用于执行上述“对接收到的信息筛选以获取所述标准API文档；解析所述标准API文档，以获得所述API特征信息；根据所述API特征信息获得API特征信息”的步骤。可选地，在应用设备100将标准API文档推送至接收装置200时，调用所述接收程序的API，以将所述标准API文档推送给所述接收程序的接口。
在本公开中，对API特征信息的具体内容并不做特殊的限定，只要用户能够在服务管理设备300中展示的API特征信息、以及API获取地址能够调用相应的应用程序即可。
作为一种可选实施方式，所述API特征信息包括所述API的类注解、所述API的接口注解、所述API的参数注解、所述API的参数对象注解、所述API的配置表、所述API的接口地址中的至少一者。
进一步可选地，所述类注解包括可以发布者信息、API所属领域、API所属类目中的至少一者。
在本公开中，对接口注解的具体内容也不做特殊的限定，可选地，所述接口注解可以包括API的名称信息、API的服务描述信息、API的内外部属性、API的限流属性、API的公共API信息中的至少一者。
在本公开中，对参数注解的内容也不做特殊的限定，可选地，所述参数注解包括参数名称、参数描述、参数默认值、参数实例值、是否必须输入属性、参数类型中的至少一者。
在本公开中，对参数对象注解的具体内容也不做特殊的限定，可选地，所述参数对象注解包括参数路径、参数名称、参数描述、参数默认值、参数示例值、参数类型、是否必须输入属性和接入协议类型中的至少一者。
一般Restful的接口参数，只有服务接口信息和参数信息，为了适应服务治理平台服务的基本属性要求，在本公开中，自定义了一套API文档生成规范，包括上述API特征信息，保证了服务属性的完整性和规范性，解决了后期再服务治理平台优化升级或者其他应用场景下的可扩展性。
服务管理设备300根据上述API信息对该服务管理设备300上的多个API进行统一分类管理，一方面便于其他用户在平台上进行查看，另一方面可以对相应领域进行权限设置，只有相应领域的用户才可进行相关API的订阅或调用权限。
例如，服务管理设备300可以通过发布者信息、API所述领域、API所述类目来限制订阅者的身份和权限。例如，当API的发布者信息表明该发布者为财务人员时，服务管理设备300将只允许财务相关用户订阅相应的API。当API所述领域为人事管理领域时，服务管理设备300将只允许人事相关用户订阅相应的API。服务治理平台可以通过内外部属性或公开API信息设置对应API文档是否对外公开。
作为一种可选实施方式，应用设备上的应用程序具有共享属性，即该应用程序在多系统中均会被调用，如短信平台、用户中心、消息通知等，通过将共享应用对应的API发布在服务管理设备300上，其他用户在设计应用程序或系统中可直接通过服务管理设备300上的API相关信息调用该应用，而无需重复开发。
网络状况不稳定、接收装置200自身情况不稳定等原因，会导致接收装置200无法获得API信息。
当网络状况不稳定导致接收装置200无法接收到标准API文档、进而导致无法获得API信息时，安装在应用设备100中的第一可执行程序(即，插件程序)会接收到发送失败的信息，以供应用程序发布者进行相应的错误排查等处理。为了提供更流畅的服务，应用设备100接收到所述接收失败信息时，继续运行所述应用程序。也就是说，应用设备100的插件程序提供一种无感式的服务，无论是否成功推送标准API文档，均能够提供稳定的应用服务，不会对应用程序的正常运行造成任何影响。
在应用设备100中的应用程序重启后，会重新推送发送失败的所述标准API文档。
作为一种可选实施方式，接收装置200的第一可执行程序独立于服务管理设备300的系统运行，且进行了高可靠性设置。接收到API文档信息后，接收装置200会立即将API文档信息保存至缓存中，如redis数据库。在后续解析等操作过程中，即使接收装置200存在系统不稳定等情况导致API文档信息丢失，也可在缓存中找到对应的API文档信息，无需请求应用设备进行发送。
服务管理设备300展示API时，所需要展示的参数可能多于接收装置200从标准API文档中解析获得的参数，作为一种可选实施方式，所述服务管理设备300将解析获得的API特征信息作为API特征信息直接展示。作为另一种可选实施方式，接收装置200还对解析获得的所述API特征信息补充默认值。相应地，服务管理设备300展示补充过默认值的API特征信息。可以理解，API特征信息可以是直接解析的API文档中的信息，也可以是解析后补充过默认值的API文档信息。
在本公开中，对接收装置200所补充的默认值并不做特殊的限定。例如，所述默认值可以是限流属性等。可以根据API对应的应用程序所述的领域、以及所述应用程序的唯一标识进行默认值的设定。例如，当所述默认值为限流属性时，对于某些应用程序对应的API，所述限流属性的默认值可以为“不 限流”。如上文中所述，通过本公开所提供的API发布系统，可以确保服务管理设备中展示的永远是处于最新版本的API。
作为本公开的一种实施方式，接收装置200还用于判断API是否发生变动。
具体地，所述接收装置200的第二可执行程序还被配置为当所述第二处理器调用所述第二可执行程序时实现以下操作：根据所述API特征信息与存储在本地的API特征信息进行对比，以判断所述API特征信息对应的API是否发生变动。
在本公开中，所述API变动包括已有API更新和新增API两种情况。也就是说，应用设备100可以通过所述插件程序发布新的API，也可以通过所述插件程序更新API。
相应地，接收装置200的第二可执行程序还被配置为当所述第二处理器调用所述第二可执行程序是实现以下操作：
根据所述API特征信息与存储在本地的API特征信息进行对比，以判断所述API特征信息对应的API是否发生变动。
具体地，每个API都对应有服务名称，接收装置200可以将提取到的API特征信息中的API服务名称与本地存储的API服务名称进行对比，当本地未存储有提取到的API特征信息中的API服务名称时，则判定该名称对应的API为新增API。
此外，接收装置200还用于在判定接收到的API特征信息为已有API的特征信息时，将所述接收装置200本地存储的API特征信息与接收到的API特征信息进行对比，并在对比结果不一致时判定发生了已有API更新，并将更新了的API特征信息与未更新的API信息进行整合。
为了便于对所述标准API文档进行解析，可选地，在解析所述标准API文档之前，接收装置可以将接收到的标准API文档存储至接收装置200的缓存中。
对标准API文档处理完毕、获得API特征信息后，可以将API特征信息持久化保存在接收装置200的本地，如mysql数据库。
本公开所提供的服务管理设备300除了具有作为API网关的数据源、展示API的特征信息、以及获取地址等功能之外，还可以提供网页调试API的功能。具体地，服务管理器被配置为根据API调试指令，对相应的API进行测试。
为了提高安全性，可选地，服务管理设备300还用于多后续API网关调用进行鉴权，具体地，服务管理设备300还被配置为，根据API调用指令，对发出所述API调用指令的网关进行鉴权。只有API网关通过鉴权，方允许该API网关调用相应的API。
如上文中所述，服务管理设备300可以展示API的API信息和获取地址。下面结合图2对服务管理设备300展示的内容进行详细的介绍。
图2中涉及的是云短信应用的API的相关信息。如图2中所示，服务管理设备300提供展示页面，该展示页面展示的是应用程序云短信对应的API接口的信息、以及云短信的相关信息。例如，页面展示的内容包括六个部分，分别为：
“云短信”这一个应用程序的基本信息，包括：服务描述(即，短信平台)、类目(即，短信提醒)、服务编号(即，30214)、服务提供(即，xxx短信平台)、公开烦死(即，否)、发布日期(即，yy-mm-dd)、版本号(即，1.0.0)、每秒最大调用次数(即，1000)、每小时最大调用次数(即，3600000)；
服务业务所有者信息，包括：联系人姓名、联系人工号、联系人邮箱、联系人手机。
服务技术所有者信息，包括：联系人姓名、联系人工号、联系人邮箱、联系人手机。
API服务信息，包括：服务英文名、API的接口地址、内外部API(即，本API是内部API还是外部API，对于云短信应用而言，API为外部API)、授权方式(即，ak/sk认证方式)、服务类别(即，API服务)、接入协议类型(即，restful)、方法类型(即，GET)，请求格式(即，HTTP)。
历史版本：包括版本号、变更时间、以及查看历史版本的入口。
云短信状态回查：订阅人数(即，8人)；累积调用次数(即，123456789)。
需要指出的是，在上述展示页面上还提供的订阅入口、服务调试入口、以及服务导出入口。用户可以通过页面上的服务调试入口对API进行调试，用户可以通过服务导出入口导出标准API文档，并且用户还可以通过订阅入口订阅所述API。
服务管理设备300在进行可视化的页面中，除了具有上述展示功能外，还可以支持模糊检索的功能，以便于用户在服务管理设备300中获得所需要的服务，减少对接人员的工作量。
例如，服务管理设备300中存储有“云短信”、“群发短信”两种应用的API，用于在服务管理设备300提供的可视化界面上输入“短信”进行搜索时，搜索结果可以包括“云短信”和“群发短信”两个检索结果。
服务管理设备300作为API网管的数据源和管理系统，可以提供服务关系和订阅关系的管理。
下面结合图6和图7对本公开所提供的API发布系统的一种可选实施方式的工作过程进行详细的介绍。
首先将能够执行“响应于应用程序程序的启动信号，获取API特征信息；根据所述API特征信息生成标准API文档；将所述标准API文档推送至所述接收装置”等步骤的第一可执行程序(即，插件程序)引入至应用设备100中，获取应用程序定义在API类中的各个API特征信息。获取到所需API特征信息后，生成标准API文档，调用安装在接收装置200上的第二可执行程序(即，接收程序)的API，并触发推送事件，将标准API文档推送至接收装置200。
接收装置200接收到标准API文档后，通过调用第二可执行程序解析所述标准API文档获取API特征信息，并对解析获得的API特征信息进行默认值补充。将所述接收装置200获得的API特征信息与存储在本地的信息进行对比，以判断是否发生API变动，并将所述API信息存储在接收装置200的本地。接收装置200在将所述API信息存储在本地的同时，将所述API信息推送给服务管理设备300，以供服务管理设备以服务市场的形式对进行可视化展示。
用户(即，应用程序开发商)想要将应用API发布在服务市场，首先下载相关插件(即，第一可执行程序)至用户的系统服务器(应用设备100)中，当应用启动时，触发插件事件，形成标准API文档，发送给安装有接收程序(即，第二可执行程序)的接收装置，并通过接收程序的处理后发布至服务市场，供其他用户查看和调用。
所述用户也可在服务市场查看其他用户提供的API文档，进行相关的调用等操作。除了插件触发的方式，所述用户也可以通过服务市场提供的标准API文档模版进行手动填写后发送给服务市场，实现API的发布。
此处解释应用设备可以是用户的服务器终端，服务治理平台也是服务器终端，都可以是云端系统。
作为本公开的第二个方面，提供一种API的信息推送方法，该信息推送方法应用于应用设备100，如图2所示，该信息推送方法包括：
在步骤S110中，响应于应用程序程序的启动信号，获取API特征信息；
在步骤S120中，根据所述API特征信息生成标准API文档；
在步骤S130中，将所述标准API文档推送至接收装置。
可选地，所述API特征信息包括所述API的类注解、所述API的接口注解、所述API的参数注解、所述API的参数对象注解、所述API的配置表、所述API的接口地址中的至少一者。
通过本公开所提供的信息推送方法，可以将携带应用程序的API特征信息的标准API文档主动推送给接收装置200，并通过接收装置200将最新版本的API的特征信息提供给服务管理设备300，从而可以使得服务管理设备300可以始终展示最新版本的API，降低甚至消除了代码入侵应用设备100、以及应用设备100中数据被篡改的风险，提高了应用设备100的安全性。
所述信息推送方法可以由安装在应用设备100中的插件所实现。通过应用设备100上安装的应用程序定义好API特征信息后，当应用程序启动时，会触发插件事件，通过反射原理，将API特征信息进行收集、整理、编码，形成标准API文档，并将该标准API文档推送给接收装置。
对应的，在接收装置上安装有自动接收程序(即，上文中所述的第二可 执行程序)，可实现API文档的自动接收。
当应用设备的系统运行之后，很难再对代码进行修改，这就意味着此时的代码会永远保持在最新状态，故在应用设备的系统运行时，启动所述推送方法，而且只需推送一次，即可保证服务管理装置300所展示的接口服务一直保持在最新状态，保证了服务的有效和及时同步。
相应地，所述推送方法还可以包括：
在步骤S140中，将所述标准API文档推送至所述接收装置后停止获取所述API特征信息。
受网络情况、应用设备系统稳定性的影响，有可能出现标准API文档无法正常送达接收装置200的情况。在这种情况下，所述推送方法还可以包括：
在步骤S150中，响应于所述推送失败信息、以及所述应用程序重启的信号，向所述接收装置重新发送所述标准API文档。
作为本公开的第三个方面，提供一种API特征信息的获取方法，应用于接收装置200，如图3所示，该获取方法包括：
在步骤S210中，对接收到的信息筛选以获取所述标准API文档；
在步骤S220中，解析所述标准API文档，以获得所述API特征信息。
本公开所提供的获取方法由接收装置200所执行，接收装置200接收到标准API文档后，独立于应用设备100和服务管理设备300执行上述步骤S210和步骤S220，既不会影响应用设备100中应用程序的运行，也不会影响服务管理设备300的运行。
可选地，所述获取方法还可以包括：
在步骤S230中，对解析获得的所述API特征信息补充默认值。
如上文中所述，所述默认值可以是限流属性等。
可选地，所述获取方法还包括在步骤S220之后进行的：
在步骤S240中，根据所述API特征信息与存储在本地的API特征信息进行对比，以判断所述API特征信息对应的API是否发生变动。
在本公开中，所述API变动包括已有API更新和新增API两种情况。也就是说，应用设备100可以通过所述插件程序发布新的API，也可以通过所 述插件程序更新API。
相应地，接收装置200还被配置为根据所述API特征信息与存储在本地的API特征信息进行对比，以判断所述API特征信息对应的API是否发生变动。
具体地，每个API都对应有服务名称，接收装置200可以将提取到的API特征信息中的API服务名称与本地存储的API服务名称进行对比，当本地未存储有提取到的API特征信息中的API服务名称时，则判定该名称对应的API为新增API。
为了便于对所述标准API文档进行解析，可选地，所述获取方法还包括：
在步骤S250中，将所述API特征信息持久化保存在本地。
为了确保可以向服务管理装置提供API信息，可选地，所述获取方法包括：
在步骤S260中，接收所述标准API文档失败时，，将所述标准API文档存储在本地。
为了便于对所述标准API文档进行解析，可选地，可选地，所述获取方法还包括在解析所述标准API文档之前进行的：
将所述标准API文档保存在缓存中。
作为本公开的第四个方面，提供一种API发布方法，所述API发布方法由服务管理装置300执行，如图4所示，所述API发布方法包括：
在步骤S310中，接收所述接收装置解析获得的API特征信息；
在步骤S320中，展示所述API特征信息。
如上文中所述，服务管理装置300通过上述方法对API进行可视化展示，可以共用户查看和订阅。
可选地，所述API发布方法还包括：
在步骤S330中，根据API调用指令，对发出所述API调用指令的网关进行鉴权；和/或
在步骤S340中，根据API调试指令，对相应的API进行调试。
作为本公开的第六个方面，提供一种计算机可读存储介质，其上存储有 可执行程序，当所述可执行程序被调用时能够实现以下方法中的任意一者：
本公开第二个方面所提供的推送方法；
本公开第三方面所提供的获取方法；
本公开第四个方面所提供的API发布方法。
本领域普通技术人员可以理解，上文中所公开方法中的全部或某些步骤、系统、装置中的功能模块/单元可以被实施为软件、固件、硬件及其适当的组合。在硬件实施方式中，在以上描述中提及的功能模块/单元之间的划分不一定对应于物理组件的划分；例如，一个物理组件可以具有多个功能，或者一个功能或步骤可以由若干物理组件合作执行。某些物理组件或所有物理组件可以被实施为由处理器，如中央处理器、数字信号处理器或微处理器执行的软件，或者被实施为硬件，或者被实施为集成电路，如专用集成电路。这样的软件可以分布在计算机可读介质上，计算机可读介质可以包括计算机存储介质(或非暂时性介质)和通信介质(或暂时性介质)。如本领域普通技术人员公知的，术语计算机存储介质包括在用于存储信息(诸如计算机可读指令、数据结构、程序模块或其它数据)的任何方法或技术中实施的易失性和非易失性、可移除和不可移除介质。计算机存储介质包括但不限于RAM、ROM、EEPROM、闪存或其它存储器技术、CD-ROM、数字多功能盘(DVD)或其它光盘存储、磁盒、磁带、磁盘存储或其它磁存储装置、或者可以用于存储期望的信息并且可以被计算机访问的任何其它的介质。此外，本领域普通技术人员公知的是，通信介质通常包含计算机可读指令、数据结构、程序模块或者诸如载波或其它传输机制之类的调制数据信号中的其它数据，并且可包括任何信息递送介质。
作为本公开的第六个方面，提供一种应用设备，所述应用服务器包括：
第一存储模块，其上存储有第一可执行程序；
一个或多个第一处理器，所述一个或多个第一处理器能够调用所述第一可执行程序，以使得所述一个或多个第一处理器实现本公开第二个方面所提供的推送方法。
所述应用设备还可以包括一个或多个I/O第一接口，连接在所述第一处理 器与第一存储模块之间，配置为实现所述第一处理器与第一存储模块的信息交互。
第一处理器为具有数据处理能力的器件，其包括但不限于中央处理器(CPU)等；第一存储模块为具有数据存储能力的器件，其包括但不限于随机存取存储器(RAM，更具体如SDRAM、DDR等)、只读存储器(ROM)、带电可擦可编程只读存储器(EEPROM)、闪存(FLASH)。
第一I/O接口连接在第一处理器与第一存储模块间，能实现第一处理器与第一存储模块的信息交互，其包括但不限于数据总线(Bus)等。
在一些实施例中，第一处理器、第一存储模块和第一I/O接口通过总线相互连接，进而与显示终端的其它组件连接。
作为本公开的第七个方面，提供一种接收装置，所述接收装置包括：
第二存储模块，其上存储有第二可执行程序；
一个或多个第二处理器，所述一个或多个第二处理器能够调用所述第二可执行程序，以使得所述一个或多个第二处理器实现根据本公开第三个方面所提供的获取方法。
所述接收装置还可以包括一个或多个I/O第二接口，连接在所述第二处理器与第二存储模块之间，配置为实现所述第二处理器与第二存储模块的信息交互。
第二处理器为具有数据处理能力的器件，其包括但不限于中央处理器(CPU)等；第一存储模块为具有数据存储能力的器件，其包括但不限于随机存取存储器(RAM，更具体如SDRAM、DDR等)、只读存储器(ROM)、带电可擦可编程只读存储器(EEPROM)、闪存(FLASH)。
第二I/O接口连接在第二处理器与第二存储模块间，能实现第二处理器与第二存储模块的信息交互，其包括但不限于数据总线(Bus)等。
在一些实施例中，第二处理器、第二存储模块和第二I/O接口通过总线相互连接，进而与显示终端的其它组件连接。
作为本公开的第八个方面，提供一种服务管理设备，所述服务管理设备包括：
第三存储模块，其上存储有第三可执行程序；
一个或多个第三处理器，所述一个或多个第三处理器能够调用所述第三可执行程序，以使得所述一个或多个第三处理器实现根据权利要求本公开第四个方面所提供的API发布方法。
所述服务管理设备还可以包括一个或多个I/O第二接口，连接在所述第三处理器与第三存储模块之间，配置为实现所述第三处理器与第三存储模块的信息交互。
第三处理器为具有数据处理能力的器件，其包括但不限于中央处理器(CPU)等；第一存储模块为具有数据存储能力的器件，其包括但不限于随机存取存储器(RAM，更具体如SDRAM、DDR等)、只读存储器(ROM)、带电可擦可编程只读存储器(EEPROM)、闪存(FLASH)。
第三I/O接口连接在第三处理器与第三存储模块间，能实现第三处理器与第三存储模块的信息交互，其包括但不限于数据总线(Bus)等。
在一些实施例中，第三处理器、第三存储模块和第三I/O接口通过总线相互连接，进而与显示终端的其它组件连接。
可以理解的是，以上实施方式仅仅是为了说明本公开的原理而采用的示例性实施方式，然而本公开并不局限于此。对于本领域内的普通技术人员而言，在不脱离本公开的精神和实质的情况下，可以做出各种变型和改进，这些变型和改进也视为本公开的保护范围。

Claims (24)

  1. 一种应用程序接口发布系统，包括接收装置、服务管理设备和至少一个应用设备，
    所述应用设备包括：
    第一存储模块，其上存储有第一可执行程序；
    一个或多个第一处理器，所述一个或多个第一处理器能够调用所述第一可执行程序，以使得所述一个或多个第一处理器实现以下操作：
    响应于应用程序的启动信号，获取所述应用程序的API特征信息；
    根据所述API特征信息生成标准API文档；
    将所述标准API文档推送至所述接收装置；
    所述接收装置包括：
    第二存储模块，其上存储有第二可执行程序；
    一个或多个第二处理器，所述一个或多个第二处理器能够调用所述第二可执行程序，以使得所述一个或多个第二处理器实现以下操作：
    获取所述标准API文档；
    解析所述标准API文档，以获得所述API特征信息；
    所述服务管理设备包括：
    第三存储模块，其上存储有第三可执行程序；
    一个或多个第三处理器，所述一个或多个第三处理器能够调用所述第三可执行程序，以使得所述一个或多个第三处理器实现以下操作：
    接收并展示所述接收装置解析获得的API特征信息。
  2. 根据权利要求1所述的API发布系统，其中，所述接收装置执行的获取所述标准API文档的步骤包括：
    对所述接收装置接收到的信息进行筛选，以获得所述标准API文档。
  3. 根据权利要求1所述的API发布系统，其中，所述API特征信息包括 所述API的类注解、所述API的接口注解、所述API的参数注解、所述API的参数对象注解、所述API的配置表、所述API的接口地址中的至少一者。
  4. 根据权利要求1所述的API发布系统，其中，所述第一可执行程序还被配置为当所述第一处理器调用所述第一可执行程序时，实现以下操作：
    将所述标准API文档推送至所述接收装置后停止获取所述API特征信息。
  5. 根据权利要求1所述的API发布系统，其中，所述第二可执行程序还被配置为当所述第二处理器调用所述第二可执行程序时实现以下操作：
    解析所述标准API文档之前，将所述标准API文档存储在所述接收装置的缓存中。
  6. 根据权利要求1至5中任意一项所述的API发布系统，其中，所述第二可执行程序还被配置为当所述第二处理器调用所述第二可执行程序时实现以下操作：
    对解析获得的所述API特征信息补充默认值。
  7. 根据权利要求6所述的API发布系统，其中，所述第二可执行程序还被配置为当所述第二处理器调用所述第二可执行程序时实现以下操作：
    根据所述接收装置获得的API特征信息与存储在本地的API特征信息进行对比，以判断所述API特征信息对应的API是否发生变动。
  8. 根据权利要求7所述的API发布系统，其中，所述API变动包括：已有API更新或新增API。
  9. 根据权利要求7所述的API发布系统，其中，所述第二可执行程序还被配置为当所述第二处理器调用所述第二可执行程序时实现以下操作：
    将所述API特征信息保存在所述接收装置本地。
  10. 根据权利要求1-9中任意一项所述的API发布系统，其中，所述应用程序包括短信平台、用户中心、宿管系统、消息通知中的至少一种。
  11. 一种API的信息推送方法，应用于应用设备，所述信息推送方法包括：
    响应于应用程序程序的启动信号，获取所述应用程序的API特征信息；
    根据所述API特征信息生成标准API文档；
    将所述标准API文档推送至接收装置。
  12. 根据权利要求11所述的推送方法，其中，所述API特征信息包括所述API的类注解、所述API的接口注解、所述API的参数注解、所述API的参数对象注解、所述API的配置表、所述API的接口地址中的至少一者。
  13. 根据权利要求11或12所述的推送方法，其中，所述推送方法还包括：
    将所述标准API文档推送至所述接收装置后停止获取所述API特征信息。
  14. 一种API特征信息的获取方法，应用于接收装置，所述获取方法包括：
    对接收到的信息筛选以获取所述标准API文档；
    解析所述标准API文档，以获得所述API特征信息。
  15. 根据权利要求14所述的获取方法，其中，所述获取方法还包括：
    对解析获得的所述API特征信息补充默认值。
  16. 根据权利要求14所述的获取方法，其中，所述获取方法还包括在获得API特征信息后进行的：
    根据所述API特征信息与存储在本地的API特征信息进行对比，以判断所述API特征信息对应的API是否发生变动。
  17. 根据权利要求16所述的获取方法，其中，所述API变动包括：已有API更新或新增API。
  18. 根据权利要求16所述的获取方法，其中，所述获取方法还包括：
    将所述API特征信息持久化保存在本地。
  19. 根据权利要求14至18中任意一项所述的获取方法，其中，所述获取方法还包括在解析所述标准API文档之前进行的：
    将所述标准API文档保存在缓存中。
  20. 一种API发布方法，应用于服务管理设备，所述API发布方法包括：
    接收所述接收装置解析获得的API特征信息，其中，所述API特征信息由权利要求15至21中任意一项所述的获取方法所得到；
    展示所述API特征信息。
  21. 一种计算机可读存储介质，其上存储有可执行程序，当所述可执行程序被调用时能够实现以下方法中的任意一者：
    权利要求11至13中任意一项所述的推送方法；
    权利要求14至19中任意一项所述的获取方法；
    权利要求20所述的API发布方法。
  22. [根据细则26改正03.09.2020]
    一种应用设备，所述应用设备包括：
    第一存储模块，其上存储有第一可执行程序；
    一个或多个第一处理器，所述一个或多个第一处理器能够调用所述第一可执行程序，以使得所述一个或多个第一处理器实现根据权利要求11至13 中任意一项所述的推送方法。
  23. [根据细则26改正03.09.2020]
    一种接收装置，所述接收装置包括：
    第二存储模块，其上存储有第二可执行程序；
    一个或多个第二处理器，所述一个或多个第二处理器能够调用所述第二可执行程序，以使得所述一个或多个第二处理器实现根据权利要求14至19中任意一项所述的获取方法。
  24. [根据细则26改正03.09.2020]
    一种服务管理设备，所述服务管理设备包括：
    第三存储模块，其上存储有第三可执行程序；
    一个或多个第三处理器，所述一个或多个第三处理器能够调用所述第三可执行程序，以使得所述一个或多个第三处理器实现根据权利要求20所述的API发布方法。
PCT/CN2020/098144 2020-06-24 2020-06-24 发布系统、推送方法、应用设备、接收装置及服务管理设备 WO2021258340A1 (zh)

Priority Applications (3)

Application Number Priority Date Filing Date Title
PCT/CN2020/098144 WO2021258340A1 (zh) 2020-06-24 2020-06-24 发布系统、推送方法、应用设备、接收装置及服务管理设备
CN202080001101.4A CN114144761A (zh) 2020-06-24 2020-06-24 发布系统、推送方法、应用设备、接收装置及服务管理设备
US17/293,641 US20220308949A1 (en) 2020-06-24 2020-06-24 Publishing system, pushing method, application device, receiving device and service management device

Applications Claiming Priority (1)

Application Number Priority Date Filing Date Title
PCT/CN2020/098144 WO2021258340A1 (zh) 2020-06-24 2020-06-24 发布系统、推送方法、应用设备、接收装置及服务管理设备

Publications (1)

Publication Number Publication Date
WO2021258340A1 true WO2021258340A1 (zh) 2021-12-30

Family

ID=79282509

Family Applications (1)

Application Number Title Priority Date Filing Date
PCT/CN2020/098144 WO2021258340A1 (zh) 2020-06-24 2020-06-24 发布系统、推送方法、应用设备、接收装置及服务管理设备

Country Status (3)

Country Link
US (1) US20220308949A1 (zh)
CN (1) CN114144761A (zh)
WO (1) WO2021258340A1 (zh)

Cited By (1)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
CN114036031A (zh) * 2022-01-05 2022-02-11 阿里云计算有限公司 一种企业数字中台中资源服务应用的调度系统和方法

Families Citing this family (2)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
US20230015697A1 (en) * 2021-07-13 2023-01-19 Citrix Systems, Inc. Application programming interface (api) authorization
CN115221530B (zh) * 2022-09-15 2022-12-23 平安银行股份有限公司 Sdlc流程中接口安全扫描方法、设备及系统

Citations (3)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
CN105278946A (zh) * 2015-06-12 2016-01-27 浙江大学 一种RESTful API可视化方法
CN107193570A (zh) * 2017-05-31 2017-09-22 郑州云海信息技术有限公司 一种自动生成api文档的方法及系统
US20190303135A1 (en) * 2018-03-30 2019-10-03 International Business Machines Corporation Intelligent discovery and application of api changes for application migration

Family Cites Families (8)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
WO2017023276A1 (en) * 2015-07-31 2017-02-09 Hewlett Packard Enterprise Development Lp Discovering and publishing api information
JP6672808B2 (ja) * 2016-01-13 2020-03-25 富士通株式会社 情報処理装置、実行時間補正方法、および実行時間補正プログラム
CN108111629A (zh) * 2018-01-19 2018-06-01 京东方科技集团股份有限公司 应用编程接口服务装置和应用编程接口服务系统
US10761838B2 (en) * 2018-07-31 2020-09-01 Dell Products L.P. Generating unified and dynamically updatable application programming interface documentation from different sources
US20200204461A1 (en) * 2018-12-20 2020-06-25 Gemini Open Cloud Computing Inc. Automation system for testing and publishing of web service
US11740884B2 (en) * 2019-09-19 2023-08-29 International Business Machines Corporation Migrating a service to a version of an application programming interface
US10915378B1 (en) * 2019-10-29 2021-02-09 Sap Se Open discovery service
US11409642B2 (en) * 2020-01-13 2022-08-09 Fujitsu Limited Automatic parameter value resolution for API evaluation

Patent Citations (3)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
CN105278946A (zh) * 2015-06-12 2016-01-27 浙江大学 一种RESTful API可视化方法
CN107193570A (zh) * 2017-05-31 2017-09-22 郑州云海信息技术有限公司 一种自动生成api文档的方法及系统
US20190303135A1 (en) * 2018-03-30 2019-10-03 International Business Machines Corporation Intelligent discovery and application of api changes for application migration

Cited By (2)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
CN114036031A (zh) * 2022-01-05 2022-02-11 阿里云计算有限公司 一种企业数字中台中资源服务应用的调度系统和方法
CN114036031B (zh) * 2022-01-05 2022-06-24 阿里云计算有限公司 一种企业数字中台中资源服务应用的调度系统和方法

Also Published As

Publication number Publication date
US20220308949A1 (en) 2022-09-29
CN114144761A (zh) 2022-03-04

Similar Documents

Publication Publication Date Title
WO2021258340A1 (zh) 发布系统、推送方法、应用设备、接收装置及服务管理设备
WO2021180025A1 (zh) 一种消息处理方法、装置、电子设备及介质
US9645880B2 (en) Supportability framework for mobile software applications
CN111245900B (zh) 一种分布式消息发送的处理系统及其处理方法
CN108804215B (zh) 一种任务处理方法、装置以及电子设备
CN110968603B (zh) 一种数据访问方法及装置
US8326913B2 (en) Method and system for service contract discovery
CN115587575A (zh) 数据表创建方法、目标数据查询方法、装置及设备
CN111666134A (zh) 一种分布式任务调度的方法和系统
US9665416B1 (en) Asynchronous execution of computer operations
CN113315750B (zh) 一种Kafka消息发布方法、装置及存储介质
CN114153703A (zh) 微服务的异常定位方法、装置、电子设备和程序产品
CN113590354A (zh) 基于区块链的信息推送方法、装置、设备、介质和程序产品
CN108874531B (zh) 用于熔断服务的方法、装置、系统及电子设备
CN110674153B (zh) 一种数据一致性检测方法、装置及电子设备
JP2022542203A (ja) ミニプログラムのバッチ処理方法、装置、電子機器及び可読記憶媒体
CN110324722B (zh) 直播间中数据的获取方法、装置、设备和存储介质
US10067808B2 (en) Nondeterministic operation execution environment utilizing resource registry
US9374437B2 (en) Schema validation proxy
CN114928603B (zh) 客户端软件的升级方法、装置、电子设备和介质
CN112241332B (zh) 一种接口补偿的方法和装置
CN114860468A (zh) 一种sdk调用方法、装置、计算机设备及存储介质
CN111552907A (zh) 消息处理方法、装置、设备和存储介质
WO2021147375A1 (zh) 数据管理方法、装置、设备、计算机可读存储介质及系统
CN112306324B (zh) 信息处理方法、装置、设备和介质

Legal Events

Date Code Title Description
121 Ep: the epo has been informed by wipo that ep was designated in this application

Ref document number: 20941638

Country of ref document: EP

Kind code of ref document: A1

NENP Non-entry into the national phase

Ref country code: DE

122 Ep: pct application non-entry in european phase

Ref document number: 20941638

Country of ref document: EP

Kind code of ref document: A1

32PN Ep: public notification in the ep bulletin as address of the adressee cannot be established

Free format text: NOTING OF LOSS OF RIGHTS PURSUANT TO RULE 112(1) EPC (EPO FORM 1205 DATED 14/02/2023)

122 Ep: pct application non-entry in european phase

Ref document number: 20941638

Country of ref document: EP

Kind code of ref document: A1