System for the automatic generation and execution of RESTful APIs

Abstract

The invention relates to a system for the automatic generation and execution of RESTful APIs. The system according to the invention is characterized by a central computing facility providing a microservice module (1), an API abstraction module (2), an API repository (3) and an API generation module (4), wherein: - the API abstraction module (2) is set up to receive API documentation from the microservice module (1), to extract API properties from the API documentation, to categorize and abstract these properties, and to store them in the form of an API definition in the API repository (3); - the API generation module (4) is configured to receive an API request (5), comprising at least one API property, from a client device (6), to access the API repository (3), to read a list from the API repository (3), comprising at least one API definition having the at least one API property, and to determine from the list a selection of APIs to be generated and executed, described by the at least one API definition; and - the API generation module (4) is further configured to generate the selected APIs into an API or API composition suitable for the API request, execute it and return it to the client device (6) in a response message.

Description

[0001] The invention relates to a system for the automatic generation and execution of RESTful APIs.

[0002] With the progressive development of powerful client devices such as smartphones and tablets, the architecture used for application development has also evolved, from simple client applications with complex server-side and application-specific backends. A large part of software development is now designed around using comparatively complex client applications and providing and synchronizing the data requested by the client applications on the server side, for example, in the form of a cloud. Such client-server systems require data exchange, i.e., communication, between machines. This is achieved through programming interfaces, also known as application programming interfaces (APIs).

[0003] Representational State Transfer (REST) ​​is a paradigm for the software architecture of distributed systems and has quickly established itself as the preferred architecture for building system APIs. REST enables stateless client-server communication and allows for the integration of heterogeneous systems.

[0004] With the increasing development of various software-as-a-service and platform-as-a-service solutions, more and more applications depend on external systems, requiring data exchange via corresponding APIs. The integration of increasingly complex external systems leads to problems. This also increases the effort required to manage and use the various APIs required by the respective applications. Since creating and integrating APIs is tedious and time-consuming, there is a need to automate this process.

[0005] US 2016 / 0092173 A1 discloses seamless RESTful API generation and consumption through a single communication channel. The document describes resource and instance management for providing APIs to a requesting client via a single communication channel.

[0006] Furthermore, US 2015 / 0128103 A1 discloses a system and method for automating API integration. The document describes configuring an API interaction sequence according to a preselected pattern request of an API service platform to adapt the API interaction sequence for third-party APIs.

[0007] Furthermore, US 2022 / 0147326 A1 discloses a method and system for automatic API code generation. The method and system disclosed in the document facilitate API development. Source code generated by the system still needs to be manually adapted according to specific requirements for a new or modified API. This involves checking, testing, and releasing the source code. The reduction in the manual effort required to generate the corresponding APIs is thus limited.

[0008] Furthermore, JP 2017-033424 A discloses a system for automatically generating APIs and a corresponding method therefor. The system comprises an API management part, an API abstraction determination part, an API abstraction part, an SDK update and processing part, and an APL SDK update and processing part. The document describes an API abstraction, whereby a system development kit is adapted to an abstracted API. Using an abstracted API, requests can be processed that contain parameters other than those in a standard case. Thus, a different use case is covered. However, this requires that all possible use cases are known in advance.

[0009] The present invention is based on the object of providing an improved system for the automatic generation and execution of RESTful APIs.

[0010] According to the invention, this object is achieved by a system for the automatic generation and execution of RESTful APIs with the features of claim 1. Advantageous embodiments and further developments emerge from the dependent claims.

[0011] A system for automatically generating and executing RESTful APIs according to the invention comprises a central computing device providing a microservice module, an API abstraction module, an API repository and an API generation module, wherein: - the API abstraction module is configured to receive API documentation from the microservice module, extract API properties from the API documentation, categorize and abstract them, and store them in the form of an API definition in the API repository; - the API generation module is configured to receive an API request, comprising at least one API property, from a client device, access the API repository, and read a list, comprising at least one API definition having the at least one API property, from the API repository, and determine from the list a selection of APIs to be generated and executed, described by the at least one API definition; and - the API generation module is further configured to generate the selected APIs into an API or API composition suitable for the API request, execute them, and transmit them back to the client device in a response message.

[0012] The system according to the invention thus allows the automatic generation and execution of RESTful APIs. This improves the reliability of a client-server system based on machine-to-machine communication using RESTful APIs.

[0013] The central computing device, e.g., in the form of a server, also referred to as a backend, provides microservices that require data exchange or communication between machines, such as information technology systems, using APIs. The microservice module provides for the use of a wide variety of APIs. Application programs executed on the client device(s) can use these APIs. The system according to the invention allows for the automatic generation and execution of the APIs requested by the respective application programs. This enables the integration and use of the respective application programs by the system according to the invention in a simple and reliable manner.

[0014] Each API documentation is described by a corresponding file, such as a YAML file. Each API documentation contains one or more API properties. These include endpoints and data points such as the API name, stage (DEV, NONPROD, PROD), region (EMEA, AMAP, CN), domain, category, version (optional), authentication (API key or token), and call method (GET, PUT, POST, DELETE), API input parameter definitions, as well as API output or response parameter definitions, including error codes. The corresponding API properties can also be specified in a specific format, such as JSON or Protobuffer. API properties can also be used to describe dependencies between multiple APIs.

[0015] By categorizing and abstracting, the API properties are combined into an API definition and brought into a certain uniform format.

[0016] For example, such a generic pattern could be: https: / / {api-name}-{stage}.{region}.{domain} / {category} / {path} / {version} / {command}. Some of these parameters can be optional, such as {command}. APIs can be categorized according to their purpose, for example, into Command APIs and Data APIs. This allows for efficient sorting and thus quickly finding the APIs you're looking for.

[0017] Each API definition is submitted to the API repository and stored there. The API repository can also be referred to as an API repository.

[0018] The client device can be, for example, a user's mobile device such as a wearable, a smartphone, a tablet computer, a laptop, a desktop computer, or the like. The client device is connected to the system via proven communication channels, in particular a communication network such as the Internet.

[0019] Thanks to the generic API request and execution patterns for the application programs running on the client devices, a specific implementation for each individual API is no longer required.

[0020] An advantageous further development of the system provides that - the API generation module is further configured to transmit generated and executed APIs to the API abstraction module; and - the API abstraction module is further configured to categorize and abstract the APIs and store them in the API repository for reuse.

[0021] This further improves the efficiency of API generation and execution. Previously generated and executed APIs can also be stored in the API repository, along with the API definitions. This means that if these APIs are requested again by client devices, they can be quickly and easily loaded from the API repository and forwarded. This eliminates the need to regenerate and execute the APIs.

[0022] According to a further advantageous embodiment of the system according to the invention, the API generation module is further configured to transmit an error message to the client device if the generation and / or execution of an API fails. This ensures seamless communication between the machines or information technology systems. This, in particular, prevents timeouts. If the client device is waiting for a corresponding API, the error message can be used to inform the client device that the corresponding API cannot be provided. Accordingly, the client device can stop waiting for the API and devote itself to another task.

[0023] A corresponding error message may also contain instructions on how to resolve the problem, for example by using an alternative API.

[0024] A further advantageous embodiment of the system according to the invention further provides that the API abstraction module is further configured to include a free-text field in a respective API definition, wherein freely definable keywords can be included in the free-text field. To enable the API generation module to correctly select the APIs to be generated and executed, it analyzes the list based on the API properties. In addition to or as an alternative to the API properties, the keywords freely included in the free-text field can be used for filtering, sorting, or searching. This enables a freer and more reliable discovery or selection of APIs to be generated and executed from the list. Corresponding keywords can, for example, be freely specified by developers in a preceding definition step.

[0025] Preferably, the API abstraction module is further configured to determine a synonym for an API property and to include the synonym as a keyword in the free-text field. Different names have been established for various API properties depending on the industry and use case. Providing appropriate synonyms further improves the reliability of API generation and execution, as differently named API properties can be appropriately addressed. For example, a translation table containing the respective synonyms for the API properties can be implemented in the API abstraction module. These synonyms are then included as keywords in the free-text field.

[0026] A further advantageous embodiment of the system according to the invention further provides that the API generation module is further configured, if the list contains at least two API definitions, to check whether and which APIs described by the API definitions are used to perform status queries and to aggregate the respective status queries into a common API. This reduces the effort required to generate and execute the APIs. If multiple status queries are to be performed, a separate API is not required for each status query; instead, multiple status queries can be included in one and the same API, which reduces the effort.

[0027] According to a further advantageous embodiment of the system according to the invention, the API generation module is further configured to determine dependencies for the APIs determined in the selection and to generate and execute the APIs according to an order resulting from the dependencies to form an API set. This further improves the reliability of communication between the machines or information technology systems and reliably ensures the provision of microservices. Different APIs can thus have dependencies on one another. Taking these dependencies into account, an appropriate order for generating and executing the APIs can be determined, thus preventing errors from occurring due to disregarding the dependencies.

[0028] A further advantageous embodiment of the system according to the invention further provides that different categorization and / or abstraction patterns are maintained in the API abstraction module for different types of client devices. Different client devices, particularly in the context of heterogeneous systems, may require API definitions predefined according to individual patterns. In other words, different client devices or the application programs executed on them require that a respective API definition has a specific format. To integrate such client devices into the system according to the invention, the categorization and / or abstraction pattern of the API abstraction module can be adapted accordingly, so that the API definition can be generated according to the formats requested by the client devices.

[0029] According to a further advantageous embodiment of the system according to the invention, the microservice module is further configured to receive new, previously unknown API documentation from an external source. By incorporating or utilizing new APIs, the service scope of the microservice module and thus of the system according to the invention can be expanded. If new APIs are developed, they can be integrated into the system according to the invention by incorporating the respective API documentation.

[0030] Also part of the invention is a method for automatically generating and executing RESTful APIs. The method provides for the execution of method steps for which the system described above is configured. Accordingly, one or more computer-readable storage media on which one or more computer program products are stored, the execution of which by a processor enables the provision of the method steps mentioned above, are also part of the invention.

[0031] Further advantageous embodiments of the system according to the invention for the automatic generation and execution of RESTful APIs also emerge from the exemplary embodiments, which are described in more detail below with reference to the figures.

[0032] Showing: Fig. 1 a schematic representation of an inventive system for the automatic generation and execution of RESTful APIs; and Fig. 2 a flow chart of the Fig. 1 illustrated system.

[0033] Fig. Figure 1 shows a system according to the invention for the automatic generation and execution of RESTful APIs, comprising a central computing device, for example in the form of a server or server network. The central computing device provides a microservice module 1, an API abstraction module 2, an API repository 3, and an API generation module 4. The system or central computing device provides microservices with the aid of the microservice module 1. Thus, the central computing device stores or manages data requested by client devices 6 for the provision of services by executing application programs.

[0034] A client device 6 can be a wide variety of devices, such as a wearable, a smartphone, a tablet computer, a laptop, a desktop computer, or preferably an embedded system, for example, embodied as a system on a chip (SoC). For example, such a system, in particular an SoC, can be embedded in a vehicle. For example, it could be a central on-board computer or a control unit of a vehicle subsystem.

[0035] Providing corresponding microservices requires communication via an application programming interface, also known as an API. The APIs used for this purpose are provided by Microservice Module 1 in the form of respective API documentation.

[0036] Arrow 101 symbolizes a classic REST request from a client device 6 for using a corresponding API. Such a request requires a specific implementation for each requested API, which involves a high level of manual user and development effort and can lead to errors due to human error.

[0037] For the automatic generation and execution of RESTful APIs, the API abstraction module 2 is configured to receive API documentation from the microservice module 1, extract API properties from the API documentation, categorize and abstract them according to predefined rules, and store them in the form of an API definition in the API repository 3. The API repository 3 is a physical, computer-readable storage medium or a storage element contained within such a storage medium. It can also be a distributed storage system, for example, distributed across one or more hard drives, SSDs, magnetic tapes, servers, or the like.

[0038] The API generation module 4 is configured to receive an API request 5, comprising at least one API property, from a client device 6, to access the API repository 3 and to read a list comprising at least one API definition having the at least one API property from the API repository 3 and to determine from the list a selection of APIs to be generated and executed, described by the at least one API definition.

[0039] The API generation module 4 generates the APIs accordingly, executes them, and sends them back to the respective client device 6 in corresponding response messages. To do this, the API generation module 4 executes steps 41 to 45. In step 41, the API generation module 4 assigns the respective API request 5 and reads the corresponding API properties. In step 42, the API properties are aggregated and the API repository 3 is accessed to compile the aforementioned list. The API generation module 4 then selects or compiles the APIs to be generated and executed. In step 43, the corresponding APIs are generated. In step 44, the corresponding APIs are executed. In step 45, a corresponding response is generated and, indicated by an arrow 102, transmitted back to the respective client device 6.The corresponding response may also contain an error message instructing the client device 6 to handle the error appropriately.

[0040] Generated and executed APIs can advantageously be forwarded from the API abstraction module 2 after categorization and abstraction to the API repository 3 for storage, so that they are available for later re-application and do not have to be regenerated or executed.

[0041] Fig. Figure 2 illustrates the process flow executed by the system according to the invention in the form of a flowchart. It shows the client device 6, the microservice module 1, the API abstraction module 2, the API generation module 4, and the API repository 3.

[0042] Steps 201 to 202 symbolize a previously common, classic process for using APIs, as shown by arrow 101. In step 201, a GET / POST API request is sent to microservice module 1. This requires a specific implementation for each API. In step 202, a response specifically crafted for this purpose is returned.

[0043] Steps 203 to 206 symbolize a first method step performed by the system according to the invention. In step 203, the microservice module 1 sends API documentation, represented, for example, by a YAML file, to the API abstraction module 2. In step 204, the API abstraction module 2 determines API properties from this. In step 205, the API properties are categorized according to predefined patterns or abstracted into new patterns. For this purpose, categorization and / or abstraction patterns that are dependent on the client device or the heterogeneity of the system 1 can be used.

[0044] In step 206, the API definitions converted from the API documentation into a specific format are stored in API repository 3.

[0045] Steps 207 to 210 can be interpreted as a second method step. In step 207, a client device 6 submits an API request 5 containing at least one API property, such as an API name, stage, region, category, version, authentication, query method, input parameters, and / or commands for execution. In step 208, the API generation module 4 queries the API repository 3 for available REST APIs. These are returned in step 209 as a list of available APIs. In step 210, the APIs to be generated and executed are selected depending on the API properties. Dependencies between APIs can also be taken into account, and a suitable generation and execution sequence for the APIs for an API composition can be determined.

[0046] Steps 211 to 215 can be interpreted as a third method step. Steps 211 to 213 are executed as a loop. In step 211, for each API definition selected, the API generation module 4 queries the corresponding API stored in the API repository 3, which is transmitted in step 212. In step 213, the corresponding API is generated by the API generation module 4. In step 214, the API generation module 4 then executes the APIs in the appropriate order. In step 215, a corresponding response message is transmitted to the client device 6.

[0047] Steps 216 to 218 can be interpreted as an optional fourth method step. In step 216, the API generation module 4 sends the generated and executed APIs, including any dependencies, to the API abstraction module 2, which, in step 217, applies the corresponding categorization and / or abstraction patterns to the APIs to categorize and abstract them. In step 218, the adapted APIs or API definitions are transmitted to the API repository 3 for supplementing and / or adapting it. QUOTES CONTAINED IN THE DESCRIPTION

[0000] This list of documents submitted by the applicant was generated automatically and is included solely for the convenience of the reader. This list is not part of the German patent or utility model application. The DPMA assumes no liability for any errors or omissions. Cited patent literature

[0000] US 2016 / 0092173 A1

[0005] US 2015 / 0128103 A1

[0006] US 2022 / 0147326 A1

[0007] JP 2017-033424 A

[0008]

Claims

[1] System for automatically generating and executing RESTful APIs, characterized by a central computing device providing a microservice module (1), an API abstraction module (2), an API repository (3) and an API generation module (4), wherein: - the API abstraction module (2) is configured to receive API documentation from the microservice module (1), to extract API properties from the API documentation, to categorize and abstract them, and to store them in the form of an API definition in the API repository (3); - the API generation module (4) is configured to receive an API request (5) comprising at least one API property from a client device (6), to access the API repository (3) and to read a list comprising at least one API definition having the at least one API property from the API repository (3) and to determine from the list a selection of APIs to be generated and executed and described by the at least one API definition; and - the API generation module (4) is further configured to generate the selected APIs into an API or API composition suitable for the API request, to execute them and to transmit them back to the client device (6) in a response message. [2] System according to claim 1, characterized by , that - the API generation module (4) is further configured to transmit generated and executed APIs to the API abstraction module (2); and - the API abstraction module (2) is further configured to categorize and abstract the APIs and to store them in the API repository (3) for reuse. [3] System according to claim 1 or 2, characterized by that the API generation module (4) is further configured to transmit an error message to the client device (6) should generation and / or execution of an API fail. [4] System according to one of claims 1 to 3, characterized by that the API abstraction module (2) is further configured to include a free text field in a respective API definition, wherein freely definable keywords can be included in the free text field. [5] System according to claim 4, characterized by that the API abstraction module (2) is further configured to determine a synonym for an API property and to include the synonym as a keyword in the free text field. [6] System according to one of claims 1 to 5, characterized bythat the API generation module (4) is further configured, if the list contains at least two API definitions, to check whether and which APIs described by the API definitions are used to perform status queries and to aggregate the respective status queries in a common API. [7] System according to one of claims 1 to 6, characterized by that the API generation module (4) is further configured to determine dependencies for the APIs determined in the selection and to generate and execute the APIs according to an order resulting from the dependencies to form an API composition. [8] System according to one of claims 1 to 7, characterized by that different categorization and / or abstraction patterns are provided in the API abstraction module (2) for different types of client devices (6). [9] System according to one of claims 1 to 8, characterized bythat the microservice module (1) is configured to receive new, previously unknown API documentation from an external source.

Images