Patent Application
20190188063
Application programming interfaces (APIs) describe ready-to-use functionalities that may be built into applications during development. An application programming interface (API) defines a way for a developer to write an application requesting functionalities from other applications or operating systems. A functionality may be provided by a function defined within a source code description of the API. In web development, application programming interfaces (APIs) are typically defined as sets of Hypertext Transfer Protocol (HTTP) request messages and definitions of response message structures in an Extensible Markup Language (XML) or JavaScript Object Notation (JSON) format. An API that utilizes HTTP requests to read, update, create, or delete (via HTTP methods GET, PUT, POST, DELETE, respectively) data is referred to as a representational state transfer (REST) API (i.e., RESTful API). Sending HTTP requests to communicate with RESTful APIs without having a documented description of functions defined within the corresponding RESTful API may be error-prone.
In distributed ledger technologies, when data are written on a computer system, the data are automatically replicated on a number of computer systems connected to the computer system in a peer-to-peer network. The data include collection of key-value pairs that represent assets in a binary and/or JSON form. Both tangible and intangible assets may be represented. The computer systems run software defining the assets and transaction instructions for modifying the assets. The software may be referred to as a smart contract. The smart contracts enforce rules for reading or altering the key-value pairs or other database information. Smart contract functions execute against the distributed ledger's current state database. Typically, smart contracts are accessed through invoke requests that include parameter values. The smart contracts blindly extract the parameter values from the invoke requests. Hence, accessing a smart contract through an HTTP request is further complicated because for an invoke request to be successful, sequence and type of the parameter values have to be correct.
The claims set forth the embodiments with particularity. The embodiments are illustrated by way of examples and not by way of limitation in the figures of the accompanying drawings in which like references indicate similar elements. The embodiments, together with its advantages, may be best understood from the following detailed description taken in conjunction with the accompanying drawings.
Embodiments of techniques for mapping computer programs to network protocol methods are described herein. In the following description, numerous specific details are set forth to provide a thorough understanding of the embodiments. One skilled in the relevant art will recognize, however, that the embodiments can be practiced without one or more of the specific details, or with other methods, components, materials, etc. In other instances, well-known structures, materials, or operations are not shown or described in detail.
Reference throughout this specification to “one embodiment”, “this embodiment” and similar phrases, means that a particular feature, structure, or characteristic described in connection with the embodiment is included in at least one of the one or more embodiments. Thus, the appearances of these phrases in various places throughout this specification are not necessarily all referring to the same embodiment. Furthermore, the particular features, structures, or characteristics may be combined in any suitable manner in one or more embodiments.
RESTful APIs may be described in accordance with various known description formats and standards. For example, source code functions of a RESTful API may be described according to an API description format such as OpenAPI™. The OpenAPI™ description format provides a way to describe available endpoints (e.g., “/users”) and methods on an endpoint (e.g., “GET /users”, “POST /users”), function input and output parameters, authentication methods, contact information, license, terms of use, etc. API specifications may be written in various formats and markup languages including, but not limited to Yet Another Markup Language (YAML), RESTful API Modeling Language (RAML), and JSON. An API specification defines a variety of functions, how the functions may be called, and what functionality the functions provide. Additionally, the API specification may provide an overview of relationships between the functions and utilizing the provided functionality to leverage the API. The API specifications provide details for functional and expected behavior of APIs, as well as fundamental design philosophy and supported data types.
In one embodiment, the mapping system 110 connects the computer system 155 to public networks such as the Internet and private networks such as an Intranet of an organization. The mapping system 110 receives requests, directed to the computer system 155. In one embodiment, the mapping system 110 manipulates the requests. For example, the mapping system 110 may convert a request received via a first network protocol (e.g., HTTP) into a request to be sent via a second network protocol (e.g., HTTP/2). As another example, the mapping system 110 may convert a RESTful API request into a remote procedure call (RPC). Alternatively, the mapping system 110 may forward the requests to the computer system 155 without amending the requests. The mapping system 110 exposes data, services, and computer programs from the computer system 155 to other networks. The mapping system 110 may be a separate unit that runs on a dedicated mapping system server (not illustrated). It should be appreciated that the mapping system 110 may also be realized as a software component rather than a hardware component and may run on a shared computer hardware together with one or more units of system 100. For example, the mapping system 110 and the computer system 155 may run on the same server.
In one embodiment, the mapping system 110 receives a request to deploy the computer program 160. The request may include the metadata 105 and source code (not illustrated) of the computer program 160. The metadata 105 include a specification of an API associated with the computer program 160. The API specification describes endpoints of functions of the computer program 160 (e.g., the endpoint 150) and input/output parameters for a function defined within the source code of the computer program 160. In addition, the metadata 105 describes an association between a function of the computer program 160 and an HTTP method. For example, the metadata 105 may include a property that is dedicated for mapping the HTTP method onto a corresponding function. The metadata 105 may be created in various languages or formats that support describing endpoints, parameters, and associations of source code functions with HTTP methods. For example, the metadata 105 may be written in a markup language such as YAML or RAML, or in a JSON format.
In one embodiment, source code of the computer program 160 is written in a high-level programming language. That is, the source code may not include descriptive information on how to interact with the computer program 160. In addition, functionality of the computer program 160 may be exposed via one or more APIs different from RESTful APIs. Therefore, the source code of the computer program 160 may be paired with the metadata 105 to provide a description of the computer program 160 to enable the mapping system 110 to expose the functionality of the computer program 160.
In one embodiment, the mapping system 110 includes a mapping generator 115 and a request generator 120. The mapping generator 115 is configured to parse the metadata 105. Based on the metadata 105, the mapping generator 115 determines a correspondence between a function of the computer program 160 and an HTTP method. For example, the mapping generator 115 may determine that the HTTP method “GET /URL” is associated with a function “read” of the computer program 160. The function is accessible at a corresponding endpoint (e.g., the endpoint 150). The computer program 160 may include one or more functions such as, for example, “read”, “write”, “update”, “delete”. The one or more functions may be accessible at one or more endpoints.
In one embodiment, the mapping generator 115 generates mappings 125. The mappings 125 are generated for the computer program 160 based on the metadata 105. The mappings 125 may include one or more mappings of HTTP methods to corresponding functions of the computer program 160. The mappings 125 include mapping 130. The mapping 130 maps method 135 to a corresponding function 140 in accordance with the metadata 105. For example, the method 135 may be a “PUT /URL” method associated with a “create” function 140 of the computer program 160 within the mapping 130. The “create” function 140 is available at a corresponding endpoint within the computer program 160.
In one embodiment, the mapping generator 115 stores the generated mappings 125 in storage 145. The storage 145 may be a database or a repository system connected to the mapping system 110. Although illustrated as an external unit to the mapping system 110, the storage 145 may also be an internal storage for the mapping system 110. For example, the storage 145 may be an in-memory database running on the same server as the mapping system 110. The storage 145 may include sets of mappings associated with a number of computer programs such as the computer program 160. The storage 145 may store mappings associated with computer programs that run on the computer system 155 or on other systems connected to the mapping system 110.
In one embodiment, the request generator 120 is configured to generate requests to the computer program 160. The requests may invoke one or more functions of the computer program 160. An invoke request to a function of the computer program 160 may include the function, one or more parameter values for one or more parameters of the function, and an endpoint within the computer program 160 where the function may be accessed.
In one embodiment, the request generator 120 generates the request based on the mapping 130. For example, the request generator 120 may generate the invoke request in response to receiving, at the mapping system 110, a request to access the computer program 160. The generation of the request to invoke one or more functions will be described in detail below, with reference to
In one embodiment, the computer program 160 is running on the computer system 155. The computer system 155 may be a personal computer, a server, a mobile device or another computing device that is capable of storing and executing computer readable instructions. The computer program 160 is associated with an endpoint 150 within the computer system 155. The endpoint 150 identifies a resource (e.g., a service or a function) within a network. One or more functions of the computer program 160 may be accessed at the endpoint 150.
At 210, a correspondence is determined between a method (e.g., an HTTP method) and a function of a computer program. The correspondence may be based on metadata of a computer program such as the computer program 160. The metadata may include a specification of an API associated with the computer program. The specification of the API includes available endpoints of functions of the computer program (e.g., the endpoint 150,
At 220, a mapping is generated between the method and the corresponding function. The mapping is stored at a storage associated with a mapping system. The storage may include a number of mapping sets for a number of computer programs. For example, the mapping may be generated by the mapping generator 115,
At 230, a request is received at the mapping system. The request includes the method, a URL, and one or more parameter values. For example, the request may be sent by a user or an application that requests access to one or more functions of the computer program.
At 240, an invoke request in automatically generated. The invoke request includes the function, the one or more parameter values, and the endpoint of the function corresponding to the method. The function is included in the invoke request based on the mapping between methods and functions that is stored at the storage. For example, the invoke request may be generated by the request generator 120,
In one embodiment, the mapping system 315 receives requests from application 320. The application 320 may be a UI application that receives user input commands and sends the deployment request in response to the commands. Alternatively, the application 320 may be an application configured to automatically send artifacts for deployment to the mapping system 315, e.g., on a predefined period of time or upon triggering of a predefined condition. One or more applications such as the application 320 may be connected to the mapping system 315.
In one embodiment, the application 320 requests deployment of a computer program on the computer system 355. For example, the application 320 may send a deployment request that includes artifacts (not illustrated) of computer program 365 to be deployed on the computer system 355. The artifacts include source code and metadata for the computer program. For example, the artifacts may include the metadata 105,
In one embodiment, the mapping system 315 receives requests from application 325. The application 325 is an application that requests services provided by the computer program 365. The application 325 may consume a functionality provided by the computer program 365 or provide the functionality to a third party. For example, the application 325 may be configured to update data in a database by invoking the “update” function of the computer program 365. In one embodiment, the application 325 communicates with the mapping system 315 via RESTful API calls. One or more applications such as the application 325 may be connected to the mapping system 315.
In one embodiment, the application 325 sends to the mapping system 315 a request to access the computer program 365. The mapping system 315 is configured to generate and render a screen 335 to a user interface (UI) 330 of the application 325. The screen 335 includes one or more HTTP methods supported by the computer program 365 and corresponding one or more endpoints at the computer system 355 where the HTTP methods may be requested. For example, the screen 335 includes method 340 that is associated with a corresponding endpoint 345. Optionally, the screen 335 may include information for parameter sequence and names to be appended to a request including the method to the associated endpoint.
In one embodiment, the mapping system 315 generates the screen 335 based on the metadata of the computer program 365. As noted above, the metadata of the computer program 365 include a specification of an API associated with the computer program 365. The specification of the API includes available endpoints of functions of the computer program 365 (e.g., the endpoint 150,
In one embodiment, the mapping system 315 is in communication with libraries 310. The libraries 310 may include one or more of configuration data, documentation, pre-written source code and subroutines, classes, values, and type specifications. Based on the libraries 310 and the storage 305, the mapping system 315 automatically generates the screen 335. The mapping system 315 renders the screen 335 to the UI 330 that runs on the application 325. The UI 330 represents a client computer program that may be part of, or may be invoked from applications such as the application 325. Examples of client computer programs include, but are not limited to, web browsers, voice browsers, application clients, and other software that may access, consume and display content.
In one embodiment, the computer system 355 is part of a distributed network 375. The distributed network 375 may include a number of systems such as the computer system 355, computer system 350, and computer system 370. The distributed network 375 may be a peer-to-peer network. Computer systems in the distributed network 375 store a distributed database record. The distributed database record may include a sequenced, tamper-resistant record of transactions executed by the computer systems in the distributed network 375 and other data. The transactions may be executed over the sequenced record or over the data. Transactions represent state transitions performed when functions of computer programs such as the computer program 365 are invoked. When a transaction is executed at a computer system of the distributed network 375, the transaction is automatically replicated to copies of the sequenced record associated with the number of computer systems. A transaction creates a set of asset key-value pairs that are committed to the record as creates, updates, or deletes. Each computer system in the distributed network 375 maintains a copy of the record. For example, the computer systems 355, 350, and 370 may be referred to as nodes of a blockchain. A node of the blockchain is associated with a corresponding database (not illustrated) storing a copy of a distributed database record associated with the blockchain. Computer programs such as the computer program 365 may run on one or more of the blockchain nodes and may execute transactions over local copies of the distributed database record. The transactions may be automatically replicated across the blockchain nodes.
At 420, a selection input including the method is received at the mapping system. The selection input may be provided by a user that views the screen. Alternatively, the input may be provided by an application configured to automatically provide input (e.g., based on predefined criteria) when the screen is rendered. In addition to the selection input, at 425, one or more values of one or more parameters of the computer program are received. At 430, a request to access the function is automatically generated. The request includes the method, the endpoint, and one or more values of the one or more parameters.
At 435 (
At 450, the request generator automatically generates an invoke request. The invoke request includes the function, the endpoint, and the one or more parameter values. At 455, the invoke request is sent to the endpoint.
In one embodiment, the metadata 520 corresponds to the function 510. The metadata 520 defines an HTTP method “POST” as corresponding to the function 510 “create”. The metadata 520 represents an API specification of an API defined by source code of the function 510. The metadata 520 includes a summary of functionality provided by the function 510, specifies parameters of the function 510, and specifies HTTP response codes and corresponding labels for responses returned by the function 510. In addition, the metadata 520 includes a property “OperationID” that is mapped to the function 510 “create”. Based on the value of the property “OperationID”, the metadata 520 specifies correspondence between the HTTP method “POST” and the function 510 “create”.
Source code of a computer program may be written in a high-level programming language and may not include descriptive information on how to interact with the computer program. In addition, functionality of the computer program 160 may be exposed via one or more APIs that are different from RESTful APIs. Therefore, a system is described that maps an HTTP method to a function of a computer program. The mapping is generated based on metadata associated with the computer program. The metadata includes a specification of an API associated with the computer program. The API specification defines HTTP methods that correspond to functions of the computer program. An HTTP method is associated with a corresponding function of the computer program via an “OperationID” property in the metadata of the function. The system automatically translates, based on the generated mapping, requests that include HTTP methods into requests including functions of the computer program and sends the requests to the computer program. Pairing the source code of the computer program with the metadata provides a description of the computer program. Thus, a function of the computer program may be requested via a RESTful API call without having a documented description of functions defined within the corresponding RESTful API and the corresponding source code of the program.
Some embodiments may include the above-described methods being written as one or more software components. These components, and the functionality associated with each, may be used by client, server, distributed, or peer computer systems. These components may be written in a computer language corresponding to one or more programming languages such as, functional, declarative, procedural, object-oriented, lower level languages and the like. They may be linked to other components via various application programming interfaces and then compiled into one complete application for a server or a client. Alternatively, the components maybe implemented in server and client applications. Further, these components may be linked together via various distributed programming protocols. Some example embodiments may include remote procedure calls being used to implement one or more of these components across a distributed programming environment. For example, a logic level may reside on a first computer system that is remotely located from a second computer system containing an interface level (e.g., a graphical user interface). These first and second computer systems can be configured in a server-client, peer-to-peer, or some other configuration. The clients can vary in complexity from mobile and handheld devices, to thin clients and on to thick clients or even other servers.
The above-illustrated software components are tangibly stored on a computer readable storage medium as instructions. The term “computer readable storage medium” should be taken to include a single medium or multiple media that stores one or more sets of instructions. The term “computer readable storage medium” should be taken to include any physical article that is capable of undergoing a set of physical changes to physically store, encode, or otherwise carry a set of instructions for execution by a computer system which causes the computer system to perform any of the methods or process steps described, represented, or illustrated herein. A computer readable storage medium may be a non-transitory computer readable storage medium. Examples of a non-transitory computer readable storage media include, but are not limited to: magnetic media, such as hard disks, floppy disks, and magnetic tape; optical media such as CD-ROMs, DVDs and holographic devices; magneto-optical media; and hardware devices that are specially configured to store and execute, such as application-specific integrated circuits (“ASICs”), programmable logic devices (“PLDs”) and ROM and RAM devices. Examples of computer readable instructions include machine code, such as produced by a compiler, and files containing higher-level code that are executed by a computer using an interpreter. For example, an embodiment may be implemented using Java® programming language, C++, or other object-oriented programming language and development tools. Another embodiment may be implemented in hard-wired circuitry in place of, or in combination with machine readable software instructions.
A data source is an information resource. Data sources include sources of data that enable data storage and retrieval. Data sources may include databases, such as, relational, transactional, hierarchical, multi-dimensional (e.g., OLAP), object oriented databases, and the like. Further data sources include tabular data (e.g., spreadsheets, delimited text files), data tagged with a markup language (e.g., XML data), transactional data, unstructured data (e.g., text files, screen scrapings), hierarchical data (e.g., data in a file system, XML data), files, a plurality of reports, and any other data source accessible through an established protocol, such as, Open Data Base Connectivity (ODBC), produced by an underlying software system (e.g., ERP system), and the like. Data sources may also include a data source where the data is not tangibly stored or otherwise ephemeral such as data streams, broadcast data, and the like. These data sources may include associated data foundations, semantic layers, management systems, security systems and so on.
In the above description, numerous specific details are set forth to provide a thorough understanding of embodiments. One skilled in the relevant art will recognize, however that the embodiments may be practiced without one or more of the specific details or with other methods, components, techniques, etc. In other instances, well-known operations or structures are not shown or described in detail.
Although the processes illustrated and described herein include series of steps, it will be appreciated that the different embodiments are not limited by the illustrated ordering of steps, as some steps may occur in different orders, some concurrently with other steps apart from that shown and described herein. In addition, not all illustrated steps may be required to implement a methodology in accordance with the one or more embodiments. Moreover, it will be appreciated that the processes may be implemented in association with the apparatus and systems illustrated and described herein as well as in association with other systems not illustrated.
The above descriptions and illustrations of embodiments, including what is described in the Abstract, is not intended to be exhaustive or to limit the one or more embodiments to the precise forms disclosed. While specific embodiments of, and examples for, the one or more embodiments are described herein for illustrative purposes, various equivalent modifications are possible within the scope, as those skilled in the relevant art will recognize. These modifications may be made in light of the above detailed description. Rather, the scope is to be determined by the following claims, which are to be interpreted in accordance with established doctrines of claim construction.
