System and method for a neutral application programming interface

Abstract

The present invention discloses a system and method for a neutral application programming interface. In one embodiment, the present invention relates to a system for a neutral application programming interface. The system may include a device. The device may be configured to receive a request. The request may include an external payload and an internal payload. The device may be further configured to parse the external payload based on a common definition of the external payload. The device may be further configured to extract information of an action from the external payload. The device may be further configured to parse the internal payload based on a definition of the action. The device may be further configured to process the action.

Description

[0001] This invention patent application is a divisional application of the invention patent application with application date of January 5, 2016, application number 201680004969.3 and invention name “System and method for neutral application programming interface”.

[0002] This application claims priority to U.S. Provisional Patent Application No. 62 / 100,406 filed on January 6, 2015, U.S. Provisional Patent Application No. 62 / 108,987 filed on January 28, 2015, U.S. Provisional Patent Application No. 62 / 144,293 filed on April 7, 2015, U.S. Provisional Patent Application No. 62 / 151,174 filed on April 22, 2015, U.S. Provisional Patent Application No. 62 / 174,394 filed on June 11, 2015, International Patent Application No. PCT / US2015 / 064242 filed on December 7, 2015, and U.S. Provisional Patent Application No. 62 / 266,060 filed on December 11, 2015, all of which are incorporated herein by reference. U.S. Provisional Patent Application No. 62 / 089,113, filed December 8, 2014, is incorporated herein by reference. Technical Field

[0003] The present invention relates generally to networking, and more particularly to the automated flow and exchange of information in device-to-device communications via a neutral application programming interface (API) mechanism. Background Art

[0004] Sometimes, devices need to communicate with each other. Sometimes this communication is to convey or report static information, such as logging or content updates or different data. One device may need to query another device to obtain the current foreign exchange rate between two currencies, or obtain stock quotes, which are time-sensitive data that fluctuates regularly. Another communication can also be transactional in nature, such as a customer presenting a credit card to a merchant for payment authorization to settle a purchase. Other device-to-device information sharing may be related to building a secure tunnel, where each device needs information such as keys, credentials, and connection settings.

[0005] An application programming interface (API) is a framework for such device-to-device communication, facilitating the automatic exchange of information from a client device issuing a query to a listening server device that answers and sends a response back to the initiating client device. A client device and a server device may constitute a pair of peers or a peer pair.

[0006] A common type of API is a request-response API POST (trigger) mechanism, which has a specific data structure payload that will be provided from the client peer to the server peer at a specific URL, and the response will be returned in a specific data structure payload. This is usually used for POST (trigger) information processed by a dedicated script on the remote server, and the result will be sent back to the initiating client device. One use of this API can be a credit card information request submitted with transaction data, such as the supplier's merchant account information, buyer-related information, and the purchase amount to be processed, where a rejection or authorization message will be returned as a response. This type of API will reject incomplete or abnormal or incorrect data structure payloads in most cases. This type of API can require compliance with security protocols, such as the presentation of certificates, HTTPS encryption, keys, or other methods. This API has advantages and disadvantages. It is ideal for single-purpose use and is designed for high-volume processing. It enables multiple third-party clients to send queries to it, such as in the case of a credit card transaction authorization API. In other use cases, the implementation may be too complex, or may not meet the needs of the purpose, such as using this type of API.

[0007] Typically, an API call made to a specific URL and path will be handled by a specific handler. If another type of API transaction is required, another URL and path will be handled by another handler and corresponding script. Each individual API call will require a certain amount of development on the client side and integration of the functionality into the system. Another consideration is the development time, work, and effort required to implement security, logging, and other necessary tasks on both the client side and the server side associated with each type of API information exchange instance when integrating the functionality into the system.

[0008] In view of the above, it should be appreciated that there may be an important need to address the shortcomings of a dedicated API POST (trigger) loop and achieve greater security and flexibility. Summary of the invention

[0009] The present invention discloses a system and method for a neutral application programming interface. In one embodiment, the present invention relates to a system for a neutral application programming interface. The system may include a device. The device may be configured to receive a request. The request may include an external payload and an internal payload. The device may be further configured to parse the external payload based on a common definition of the external payload. The device may be further configured to extract information of an action from the external payload. The device may be further configured to parse the internal payload based on a definition of the action. The device may be further configured to process the action.

[0010] According to other aspects of this embodiment, the external payload includes a timestamp of the time when the request was generated.

[0011] According to other aspects of this embodiment, the internal payload is encrypted, and the device is further configured to decrypt the internal payload.

[0012] According to other aspects of this embodiment, the device is configured not to process the action if a time interval between a time when the device receives the request and the timestamp exceeds a threshold.

[0013] According to other aspects of this embodiment, the threshold is based on network delay.

[0014] According to other aspects of this embodiment, the threshold is equal to 1 second.

[0015] According to other aspects of this embodiment, encryption of the inner payload is based on the timestamp and the action.

[0016] According to other aspects of this embodiment, the encryption of the internal payload is also based on an initiating device that initiates the request and the device.

[0017] According to other aspects of this embodiment, the request is sent via a secure socket layer.

[0018] According to other aspects of this embodiment, the internal payload includes at least one of an array, a key-value pair, an object, a data file, and a binary file.

[0019] According to other aspects of this embodiment, the device is further configured to process the action using a script.

[0020] According to other aspects of this embodiment, the device is further configured to retrieve the action from a server.

[0021] According to other aspects of this embodiment, the server is configured to store information about actions and store information about devices.

[0022] According to other aspects of this embodiment, the server is further configured to store a peer-to-peer relationship between the initiating device and the destination device.

[0023] According to other aspects of this embodiment, the device is further configured to update the action.

[0024] According to other aspects of this embodiment, the device is further configured to retrieve a list of its own peer initiating devices from the server; and listen to requests from devices in its own peer initiating device list.

[0025] According to other aspects of this embodiment, the server is further configured to push the action to the device.

[0026] According to other aspects of this embodiment, the server is further configured to mark the action to indicate availability.

[0027] According to other aspects of this embodiment, the device is further configured to:

[0028] A response to the request is sent.

[0029] According to other aspects of this embodiment, the device is further configured to include a portion of the request in the response.

[0030] In another embodiment, the present disclosure relates to a method for a neutral application programming interface. According to the method, a request can be received. The request can include an external payload and an internal payload. The external payload can be parsed based on a common definition of the external payload. Information of an action can be extracted from the external payload. The internal payload can be parsed based on a definition of the action. The action can be processed.

[0031] In yet another embodiment, the present disclosure relates to a non-transitory computer-readable medium storing a computer-readable program of a neutral application programming interface. The program may include computer-readable instructions for receiving a request. The request may include an external payload and an internal payload. The program may include computer-readable instructions for parsing the external payload based on a general definition of the external payload. The program may include computer-readable instructions for extracting information of an action from the external payload. The program may include computer-readable instructions for parsing the internal payload based on a definition of the action. The program may include computer-readable instructions for processing the action.

[0032] The present invention will now be described in more detail with reference to the specific embodiments shown in the accompanying drawings. Although the present invention is described below with reference to specific embodiments, it should be understood that the present invention is not limited thereto. A person of ordinary skill in the art can access the teachings herein and will recognize additional implementations, modifications and embodiments and other fields of use within the scope of the present invention described herein, and the present invention can be significantly useful with respect to additional implementations, modifications and embodiments and other fields of use. BRIEF DESCRIPTION OF THE DRAWINGS

[0033] In order to facilitate a more complete understanding of the present invention, reference is now made to the accompanying drawings, in which similar elements are marked with similar numerals or reference symbols. These drawings should not be construed as limiting the present invention, but are intended to be used for illustrative purposes only.

[0034] Figure 1 A flow chart showing the working principle of the application program interface according to an embodiment of the present invention is shown.

[0035] Figure 2 A flow chart of a neutral application programming interface (API) mechanism for carrying a data array within an internal payload according to an embodiment of the present invention is shown.

[0036] Figure 3 A flow chart showing API mechanism neutrality under any payload according to an embodiment of the present invention.

[0037] Figure 4 A block diagram illustrating security aspects of a neutral API mechanism according to an embodiment of the present invention.

[0038] Figure 5-A An exemplary request payload array according to an embodiment of the present invention is shown.

[0039] Figure 5-B An exemplary response payload array according to an embodiment of the present invention is shown.

[0040] Figure 6 A block diagram showing a neutral API mechanism device peer and cooperation with a central control server (SRV_CNTRL) according to an embodiment of the present invention is shown.

[0041] Figure 7 Automated device cooperation according to an embodiment of the present invention is shown.

[0042] Figure 8 The information flow between the device and the central control server according to an embodiment of the present invention is shown.

[0043] Fig. 9 A backbone switch server topology with security and open API sequence according to an embodiment of the present invention is shown.

[0044] Fig.10 An open API call that relies on internal API call completion according to an embodiment of the present invention is shown.

[0045] Fig.11 Requests / responses between peer devices and between a device and a central control server according to an embodiment of the present invention are shown.

[0046] Fig.12 A closed loop and an open loop according to an embodiment of the present invention are shown.

[0047] Fig.13 An exemplary transaction code in a request payload according to an embodiment of the present invention is shown.

[0048] Fig.14 An exemplary transaction code in a response payload according to an embodiment of the present invention is shown.

[0049] Fig.15 An exemplary mapping of elements in a request / response payload in a closed loop according to an embodiment of the present invention is shown.

[0050] Fig.16 An exemplary element mapping in a request / response payload in an open / RESTFul loop according to an embodiment of the present invention is shown.

[0051] Fig.17 The collaboration and relationship between the main modules used by the neutral API mechanism according to an embodiment of the present invention are shown. DETAILED DESCRIPTION

[0052] In some embodiments, the neutral application programming interface (API) mechanism (NAPIM) disclosed in this article can be a component of a complex type of network such as a global virtual network (GVN), and therefore needs to be dynamically expanded on many devices, and there are the following requirements: adding new API call patterns; changing existing API call patterns; using a common transport, security and logging architecture; deprecating obsolete API call patterns; having advanced functions that can transmit any payload; dynamically adding, deleting or editing API relationship information between peer pairs, including information about the peers themselves or the related peers to which these peers are connected or connected to these peers; allowing devices to act as servers or clients or both clients and devices at different times depending on their roles in a specific peer pair API transaction or relationship or transaction relationship; registering all API clients and API servers to a central server through the API peer that controls the server API call, thereby realizing dynamic updates to the API mechanism structure information matrix; and other requirements.

[0053] In some embodiments, NAPIM may be used to propagate updates, including maintaining updated lists of peer pairs, credentials between peer pairs, lists of API actions, logging, and other information.

[0054] In some embodiments, the advantage of this flexible topology is that some devices can act as clients in one information exchange or as servers in another API information exchange. The API client host can trigger an API call that sends an API request to the server host peer, and the client will parse and process the response received back. The API server host can include a listener that listens for the request POST (trigger) initiated from the API client host. After receiving the request, the API server host parses and processes the request, and then prepares a response to send back.

[0055] In some embodiments, for security reasons, the device's API listener may be turned off during times when it is not needed to act as a server, and at other times, the API listener may be turned on so that it can act as an API server.

[0056] In some embodiments, a central control server (SRV_CNTRL) may exist in the NAPIM system disclosed herein. Devices in the NAPIM system may be registered on the central control server. The central control server may manage the devices, including but not limited to the environment and software of the devices. The central control server may exist in a global virtual network. For redundancy, there may be multiple central control servers in multiple locations.

[0057] The API can be kept neutral regardless of the payload being transmitted, and the payload can be predicted by the common pattern of the outer payload, where the triggering and processing of the defined data structure of multiple possible inner payloads is determined by the specified action code. Therefore, an unlimited number of API actions are possible through NAPIM.

[0058] After the action information is presented to the relevant script trigger on the client peer, the functional state of the action may be operational, which is then transmitted through the NAPIM request sender on the client peer to the request handler and processor script on the server peer, thereby activating the script on it. The response handler script on the client peer interprets the response received from the server peer and activates the appropriate script. The script, data structure and payload for each type of API action can be replicated to each device in the peer pair through the API mechanism itself to achieve unlimited scalability.

[0059] Thus, an infinite number of possible action payloads can be carried via internal payloads and processed by NAPIM, while the general NAPIM system utilizes a common external framework for payload structures, transmitters, listeners, handlers, and other elements of the API transport.

[0060] Figure 1 A flow chart showing how the application program interface works. Figure 1 Describes the automated process flow of an Application Programming Interface (API) request-response automated information exchange transaction between two devices. Figure 1 As shown, there is a pair of peer devices D-01 and D-02. Peer initiator D-01 is a host client that is the source of the API call. At step 1, peer initiator D-01 generates an API request with a payload, which will be sent as request 102. At step 2, request 102 is received by the listening host server peer target D-02. At step 3, the API request received by peer target D-02 is processed by D-02's API handler. Based on the processing of the API call, an action can be taken. At step 4, a response based on the processed API request is prepared and sent back as response 104. At step 5, response 104 is received by peer initiator D-01. At step 6, response 104 is processed by peer initiator D-01.

[0061] In some embodiments, a security layer may be added to the request and response. The transport method may also be protected by certificates, protocols (e.g., https or http), or other methods. In some embodiments, both peer hosts D-01 and D-02 are capable of preparing and sending structured data payloads that can be interpreted, understood, and processed by the other peer.

[0062] Figure 2 A flow chart illustrating a neutral application programming interface (API) mechanism for carrying a data array as an inner payload within an outer payload is shown according to an embodiment of the present invention.

[0063] Figure 2The diagram illustrates the neutrality of the API mechanism where all request and response external payloads adhere to the same data structure pattern. In other words, all request and response external payloads follow a common definition that has the same consistent structure, fields, etc. This "same pattern" preparation, delivery, and parsing architecture enables very flexible and dynamic abstraction of the unlimited API actions that can be carried by the mechanism. This approach can also help ensure the security of data payloads wrapped in one or more security layers. An additional benefit is that the API itself becomes a delivery system for its own structure definition, and new functionality can be added to its action matrix by publishing API actions and related scripts, data structure definitions, and other related information via the API itself.

[0064] The database of the API instance running on each peer device uses tables to store information such as API_queue, peer pair data, API_transaction, API_action_index, etc. used by the API module of each device in the peer pair. More details on the software stack in the client, server and central server devices, as well as database backup integration and data replication between databases will be combined Figure 6 Discussed below. The database table names, fields, and structures described herein are examples and may be different. There may also be more or fewer tables to store API related data.

[0065] Necessary security is achieved by protecting the inner payload by encrypting it and containing an obfuscated payload as a data element of the outer payload.

[0066] Figure 2 Include Figure 1 All components of Figure 2As shown, the additional starting point step 0 of the peer initiator host (client) source D-01 illustrates the trigger of the API transaction call. Step 0 may include sub-steps D-01-A to D-01-E. In step D-01-A, data is transferred to a general class or other type of handler to create an internal payload. In step D-01-B, the internal payload is added to a queue that may be in memory, saving it to a database, flat file or other mechanism. The queue step can be bypassed or set to be sent at a certain time. In step D-01-C, as part of the heartbeat function of the client device D-01, and depending on the priority flag of the API call in the queue, the payload in the queue can be processed immediately, at a specific time, or delayed based on factors such as load, queue length, network conditions or other factors. In step D-01-D, after processing the item from the queue, the external payload is prepared. In step D-01-E, relevant transaction data will be generated for a specific, single-use API call. It can be uniquely encrypted with a key that is rotated based on time, peer in pair, action, and other factors. When the API request payload PL01 is ready to be sent in step 1, it is transmitted through the neutral API mechanism to be received by the peer target host (server) API (D-02) in step 2. Figure 2 As shown, in some embodiments, the outer payload PL01 may include information about the device, action, transaction_code, payload, IP_address, transaction type, and timestamp. The timestamp may be the time when the request / payload was generated. The payload may specify an encrypted inner payload.

[0067] Upon receiving the API request payload PL01, in step 3, the peer target D-02 may parse and interpret the API request payload PL01. Step 3 may include sub-steps D-02A to D-02-D. In step D-02-A, during the processing of the API request payload PL01, security and data integrity checks may be performed, and the payload may be decrypted to discover the contents of the inner payload. Further security and data integrity checks may be achieved by comparing the inner and outer payloads. In some embodiments, the outer payload is parsed according to the "same pattern" (i.e., common) structure of the outer payload. Information (e.g., name) of the action to be taken (e.g., AAPIAC) may be obtained. The inner payload may be parsed according to the definition of the action. For example, the inner payload may be parsed according to the definition of the action AAPIAC. In some embodiments, the definition of the action specifies the structure of the payload of the action. In step D-02-B, after verification, the payload (e.g., inner payload) is transmitted to the corresponding script to take the prescribed action. In some embodiments, the action is processed by a script or some other handler. In step D-02-C, after completing the requested action, an inner payload of the response is created, and the inner payload may include encryption of the fields. In step D-02-D, an outer payload of the response is created. In step D-02-E, relevant transaction data is generated for the response 104. At this point, the API request payload PL02 is generated.

[0068] In some embodiments, the difference between the API request payload and the API response payload may include the transaction type: REQ=request and RSP=response. In some embodiments, a timestamp for preparing the transaction is created in D-01-E and D-02-E. The difference may include different timestamps. The timestamps may be UNIX timestamps, and the processing time for multiple operations will be different. To maintain the integrity of the system, all devices may automatically update their internal clocks periodically to ensure synchronization, thereby avoiding problems caused by time drift of the clocks. The difference may include devices. For example, the [device] in the API request payload PL01 specifies the device code of the peer initiator D-01. The [device] in the API request payload PL02 specifies the device code of the peer target D-02. The transaction code in the API request payload PL01 and the transaction code in the API request payload PL02 may also be different. The IP addresses may also be different.

[0069] The payloads may also be different. The response payload PL02 is more detailed because the [Payload] element of its data structure includes an encrypted block that includes both the unencrypted request payload PL01 and the response payload. This enables the peer initiator D-01 to not only verify the integrity of the data structure of the response, but also for D-01 to receive an internal, decrypted version of its original request for comparison and verification. In step 6, the peer initiator D-01 can parse and interpret the API response payload PL02. Step 6 can include three sub-steps. The response payload is processed and verified in step D-01-F. In step D-01-G, upon successful verification, the internal decrypted response payload of PL02 can be sent to the appropriate action response handler script on the peer initiator D-01. In step D-01-H, logging and ending of the API are performed to complete the API transaction. If there is a [Callbacks] array attached to the internal decrypted response, then this array becomes a trigger for one or more new API transaction calls, which start from step 0. All new callback API calls can be processed independently without depending on or relying on past calls because D-01-H is the terminal endpoint of the API transaction call.

[0070] In some embodiments, the inner payload may include an array, a key-value pair, an object, a data file, and / or a binary file.

[0071] Figure 3 A flow chart showing API mechanism neutrality under any payload according to an embodiment of the present invention. Figure 3 It includes steps 0 to 6, a request 102, a response 104, a peer initiator D-01 and a peer target D-02.

[0072] Step 0 of the API call is the starting point. Based on the action to be taken, a specific action script can be a separate file, daemon, class, function, embedded code block or other mechanism to prepare the internal payload data structure for the specific API action to be taken.

[0073] For example, in step D-01-A, the script of action code A0-A prepares its payload and creates the inner payload of the request. For simplicity, the Figure 2 , but the reader should understand that they occur between step D-01-A and step 1. In step 1, Figure 1 and Figure 2 The request payload is sent to the peer target D-02 in a similar manner.

[0074] In step 2, the request payload is received by peer target D-02. The request payload is parsed and processed in step D-02-A. After the inner payload is successfully decrypted and passed the security and data integrity verification, and based on the action code specified by the trigger, in this example (action code A), the data structure in the inner payload is sent to the action code A script 3-A. After the response inner payload data structure is successfully handled, processed and generated, the relevant transaction data will be generated for the response 104 in step D-02-E. The response payload is sent to peer initiator D-02 in step 4 and received by peer target D-01 in step 5.

[0075] As described above, in step D-01-G, upon successful authentication, the internal decrypted response payload may be sent to the appropriate action response handler script on peer initiator D-01. Figure 3 As shown, based on the action code, the inner decrypted response payload is sent to the relevant action code script. In this example flow, action code A is processed by action code A script 6-A. This example API call transaction will terminate at D-01-H.

[0076] Similarly, if action B is included in the payload, action B will go from 0 to 0-B, then from D-01-A to 1 to 2 to 3 to D-02-A, and the request will be processed by 3-B to D-02-E to 4 to 5 to 6 to D-01-G to 6-B and terminate at D-01-H.

[0077] Similarly, if action C is included in the payload, action C will go from 0 to 0-C, then from D-01-A to 1 to 2 to IJ3 to D-02-A, and the request will be processed by 3-C to D-02-E to 4 to 5 to 6 to D-01-G to 6-C and terminated at D-01-H.

[0078] Figure 4 A block diagram illustrating security aspects of a neutral API mechanism according to an embodiment of the present invention.

[0079] In many aspects, the neutral API mechanism can operate in a similar manner to a traditional client-server request-response API call by encrypting the data packets via a secure socket layer (SSL) using a key file, certificate or other credentials (i.e., F3) for HPPS (i.e., F4) transmission 408 over the Internet F5. The transport security L2 (including 406 and 404) and network L1 elements are similar to other conventional POST (trigger)-API-calls made to a dedicated script.

[0080] The neutral API mechanism further performs several steps to increase the protection of data structure L3.

[0081] The outer payload has specific data elements for delivering the outer payload to the target device and carries an encrypted inner payload that is processed by the action code script for parsing and processing. The encryption and decryption 402 between the inner payload F1 and the outer payload F2 will secure the data payload if the HTTPS encryption is broken during transmission 408 over the Internet F5.

[0082] The encryption and decryption 402 between the inner and outer payloads can utilize specific peer pair information and other factors unique to the relationship between the client and server devices, such as key adjusters. Another element of security is that the data structure specifying the action conforms to an expected pattern. In some embodiments, the encryption of the payload can be based on a rotating key calculated using various factors including timestamp, action type, peer pair (and their associated keys and keys related to their relationship).

[0083] Security information, keys, key regulators, certificates, and other information related to securing API transactions between a peer pair may be dynamically updated via API calls between devices in the peer pair, or for each device receiving this information, via API calls to a central control server (SRV_CNTRL), a back-channel mechanism, or other methods.

[0084] There is also anti-replay functionality built into the architecture based on timestamps, transaction codes, and other factors to ensure that each API call is processed only once. This is to counter man-in-the-middle malicious attacks or mitigate the negative impact of device failures. In some embodiments, anti-replay is based on a threshold based on network latency. For example, if the network latency (e.g., expected latency in the network) between the initiating device (e.g., peer initiator D-01) and the destination device (peer target D-02) is only 1 second, and if the destination device receives the request more than 1 second after the initiating device issues the request (e.g., based on the timestamp in the request payload), the indicating device may choose not to process the request.

[0085] Figure 5-A An exemplary request payload array according to an embodiment of the present invention is shown.

[0086] Figure 5-A and Figure 5-B The diagram shows an inner payload being encrypted first and then carried within an outer payload. Figure 5-A and 5-B All based on Figure 2, and repeats many elements described in this example embodiment. Figure 2 Has been split into Figure 5-A and Figure 5-B The corresponding diagram defined. Example Embodiment Figure 5-A The diagram shows the request portion of an API call, and Figure 5-B The response section is illustrated.

[0087] Example Embodiment Section Figure 5-A The following elements are Figure 2 The elements described in the example are the same as those described in the example, such as devices D-01 and D-02 and the communication path 0 to 1 between them, including the intermediate step D-01-A through D-01-E to 1 to 2 to 3. In this example embodiment, the PL01-external and PL01-internal pairs in this example embodiment are further used. Figure 2 The payload PL01 in is described.

[0088] After decrypting the request outer payload PL01-OUTER by peer target D-02, the request inner payload PL01-inner is discovered. The data structure of PL01-inner may be a multi-dimensional array or other type of data structure. The [wrapper function] and [metadata] and [payload] and [callback] elements are presented for illustration purposes only and may contain the same or different subfields, nested arrays, links to files, file data glob modules, or other information applicable to the action performed by the server device in the peer pair invoked by the API transaction.

[0089] Figure 5-B An exemplary response payload array according to an embodiment of the present invention is shown.

[0090] Example Embodiments Section Figure 5-B The following elements are Figure 2 The elements described in FIG. 1 are the same as those described in FIG. 1 , such as devices D-01 and D-02 and communication paths 3 to 4 between them, including intermediate steps D-02-A to D-02-E to 4 to 5. In this exemplary embodiment, the PL02-external and PL02-internal pairs in this exemplary embodiment are further used. Figure 2 The payload PL02 in is described.

[0091] After decrypting the response outer payload PL02-external by the peer initiator D-01, the response inner payload PL02-inner is discovered. The data structure of PL02-inner may be similar to that of PL01-inner. However, the data structure is a response, and its main payload is the processing result of the action taken by the server. When a response is sent back, the original request (e.g., a portion of the original request or the original request) may be included as an element of the data structure. The [encapsulated function] and [metadata] and [payload] and [callback] elements in PL02-inner are presented for illustrative purposes only and may include the same or different sub-fields, nested arrays, links to files, file data glob modules, or other information applicable to the actions performed by the server device in the peer pair called by the API transaction.

[0092] Figure 6 A block diagram of a neutral API mechanism device peer and collaboration with a central control server (SRV_CNTRL) according to an embodiment of the present invention is shown. This example embodiment illustrates a logical view of the software architecture of three types of network devices working together as part of a neutral API mechanism (NAPIM) within a global virtual network (GVN) according to a specific embodiment. As shown, the software and hardware can be distributed within the network device and can be distributed across different circuit boards, processors, network interface cards, and memories.

[0093] One of the network devices is an API client (initiator) device 100 , another of the network devices is a central server SRV_CNTRL 200 , and a third device is an API server (target) device 300 .

[0094] Client device 100 can connect to access point (POP) 401 via a tunnel represented by communication path 6P1, connect to WAN 402 via 6P2, connect to POP 403 via communication path 6P4, and then connect to server device 300 via communication path 6P5. The path through WAN 402 can also be on the conventional Internet.

[0095] Each of the client device 100 and the server device 300 may also be connected to the SRV_CNTRL device 200 via 6P3.

[0096] The software architecture of the client device 100 and the server device 300 can be very similar to the difference in the role of each device in this transaction. The client device 100 has an API client module D176, and the server device 300 has an API server module D376. For the sake of simplicity in explaining this example embodiment, only one module is shown, namely D176 on the client device 100 and D376 on the server device 300. In practice, depending on the function of the device in the GVN, the device may have a combined client and server role. In practice, SRV_CNTRL is of this nature by virtue of its API client / server module D276.

[0097] The lowest level of each device is the memory D112 / D212 / D312 and the processor D110 / D210 / D310 and the network interface D120 / D220 / D320. All of these may be at the hardware level. The operating system (0 / S) D130 / D230 / D330 may be a LINUX system or an equivalent system such as Debian or other systems. This includes data packets and configurations for routing, hosting, communication and other system-level operations.

[0098] Above the operating system is the system software layer D150 / D250 / D350 of the global virtual network (GVN) operating system. Custom commands, system modules, and other components all operate here, along with other components of the GVN. Each type of device in the GVN can have some or all of these parts of the system software layer, depending on their role.

[0099] The database modules D165 / D265 / D365 and the hosting modules D160 / D260 / D360 are configured in this example embodiment to listen, send, process, store, retrieve and other related base level operations for the GVN NAPIM.

[0100] The GVN manager described in D170 / D270 / D370 provides dependent functions to the NAPIM. The recorder described in D175 / D275 / D375 in this example embodiment has the function of recording API actions and transactions. The recorder also has other roles and processes for other aspects of GVN operations.

[0101] API D172 / D272 / D372 describes the engine of NAPIM. On the API client 100, the API client module D176 on top of the API engine D172 is used to prepare API requests and also process received API responses.

[0102] On the API server device 300, the API server module D376 on the API engine D372 is used to listen to incoming API calls for processing by D372 and prepare responses to be sent back via D372.

[0103] On top of SRV_CNTRL 200, another layer is provided for the repository manager D280, which handles the coordination of sharing of peer information, credentials and other information with independent devices connected to other peers through the API mechanism of GVN.

[0104] The operating system D150 / D250 / D350 may have a file storage HFS100 / HFS200 / HFS300.

[0105] The database structure of the API-related database tables B100 / B200 / B300 is the same on each of the API client device 100 , the central server 200 , and the API server device 300 .

[0106] On SRV_CNTRL 200, repository database B 208 is used to store unique peer information for all peers, and repository manager D 280 can use this information to communicate API credentials or other information for a client or server in a peer pair that will receive information related to itself or its peers.

[0107] Each device API database B100 / B200 / B300 stores peer information about the device itself and its peer-to-peer partners, transaction lists, and queue data.

[0108] The described methods and databases have other uses besides the API, but this example embodiment only covers the API functionality aspects of the relevant devices.

[0109] Figure 7 Automated device cooperation according to an embodiment of the present invention is shown.

[0110] This example embodiment describes a set of API calls 7202, 7206, and 7208 between different types of devices within a global virtual network (GVN). Each API call is essentially a round-robin, where a request is sent from a client to a server, and a response is sent back to the client. In most cases, the client can be one or the other end of a peer pair, as long as the other peer has enabled the listening function to act as a server.

[0111] API call group 7202 represents calls from the central control server (SRV_CNTRL) 200 via path P7202-C, to the endpoint device (EPD) 100 via P7202-B and the access point server (SRV_AP) 300 via P7202-A. This type of communication can exchange information about tunnel information, log information, billing information, device peer pair data and other forms of related information between the repository database and file storage on SRV_CNTRL 200 and EPD 100 and SRV_AP 300.

[0112] There are two types of communication paths between EPD100 and SRV_AP300. The direct tunnel between them can push layer 3 traffic, information and binary files as data packets via path P7206-C. There is also an API call framework between ETO100 and SRV_AP300 via the path from P7206-B to API7206 to P7206-A.

[0113] The direct connection between Ero100 and SRV_AP300 via API7206 can be used for information sharing, collaboration and verification, as well as other information. For example, an attempt to restart a tunnel can usually be triggered by one side, with the other side automatically responding and rebuilding it. However, in the event that the tunnel is blocked and cannot be rebuilt, the API can be used to send commands to try to force the restart of the tunnel at both ends, and if it is still unsuccessful, information can be shared between the devices. This information may trigger the need to use new tunnel information to establish a different tunnel between the two devices, or cause both devices to send queries to SVR-CNTRL200 to obtain new tunnel establishment information. Therefore, it is very useful to establish a communication path between them via API7206.

[0114] API call group 7208 represents calls made by SRV CNTRL 200 and internal backend infrastructure devices and other infrastructure support devices of GVN via path P7208-C. For simplicity of explanation, some gateway devices are shown in this example embodiment, and other types of infrastructure devices in GVN that may be connected to SRV_CNTRL via this path may not be shown here.

[0115] RV_GW_Email 7310 represents an email server and is linked to API 7208 via P7200-Bl, to P7208-C, and thus to SRV_CNTRL 200. Email network access point (NAP) 7401 can send and receive email via P7401. A dedicated email server enables other devices to focus on their own functions and also provides simplified management because it is the only type of device that needs to be maintained in terms of email server management.

[0116] SRV_GW_FIN 7318 represents a financial gateway server that can be used to conduct credit card and other financial related transactions with third parties through external API 7501NAP via P501. As with the example SRV_GW_Email 7310, a device-type role that focuses on a single function enables other devices to focus on their core functions and provides simplified management because only the SRV_GW_FIN 7318 server needs to be additionally managed to protect financial transactions with third parties.

[0117] SRV_GW_Other 7315 represents other types of gateways between GVN and other services on the Internet. Communication between these types of gateway servers and SRV_CNTRL20 is achieved via P7208-B3 to API 7208 to P7208-C.

[0118] The secondary API path between SRV_AP300 and SRV_CNTRL200 is via P7208-A to API 7208 to P7208-C and exists for redundancy purposes and is used for infrastructure-related communications between the peer pair.

[0119] Another set of calls from the SRV_AP server may establish a path from SRV_AP 300 to SRV_GW_email 7310 via a path from P7208-A to API 7208 to P7208-B1, and establish a path from SRV_AP 300 to SRV_GW_FIN 7318 via a path from P7208-A to API 7208 to P7208-B2, and establish a path from SRV_AP 300 to SRV_GW_Other 7315 via a path from P7208-A to API 7208 to P7208-B3. These may implement API calls for data exchange directly from SRV_AP 300 to these devices.

[0120] API calls transmitted via P7208-A may also represent relayed API calls made by other devices via SRV_AP 300, such as a call from EPD100 to SRV_GW_FIN7318 implemented via path P7206-B to API7206 to P7206-A to SRV_AP 300 to P7208-A to API 7208 to P7208-B2, in which case the API call process implemented through SRV_AP300 is just another leg in the chain, where the client is EPD100 on one end and the server is SRV_GW_FIN7318 on the other end.

[0121] API calls and other types of information exchange are critical to the operation of devices in the GVN. In some embodiments, types of automated infrastructure operations may include: keeping device operating system configurations up to date; updating software packages for 0 / S and modules from a reliable repository source that can accommodate updated software so that patches, updates, and latest installations can be easily and predictably implemented; deploying new global virtual network software modules and keeping installed modules updated; performing controlled replication of the GVN database; keeping the API operation library up to date; and other operations.

[0122] There may be daemons and heartbeat functionality on each device that requires automation and device-to-device interaction to keep daemons running (e.g., services started, queued and keeping them unblocked, heartbeat functionality, logging functionality), connectivity, and fabric (e.g., virtual interfaces, tunnels, multiple tunnels, routing, server availability, geographic destinations, DNS, caching, and link caches working properly).

[0123] The latest information is needed for tunnel establishment and this information needs to be shared between the client and the server, otherwise the tunnel will not be able to be established.

[0124] Testing and diagnostics need to be performed, with the resulting data reported for centralized analysis to understand the overall operation of the GVN. Testing and diagnostics can include: Layer 1 conditions; tunnel connectivity; optimal point-to-point routing on the Internet; Advanced Smart Routing (ASR) for optimal routing through the GVN; device operation, etc.

[0125] The neutral API mechanism disclosed herein may be used to communicate information about itself, including but not limited to: peer pair information, queue information, transaction logs, security / billing / logging and related data, API actions, schemas, data structures, and related scripts for processing actions on the client or server.

[0126] It may be necessary to ensure that the API and hosting module architecture are up and running. Information about the status and configuration of the hosted service can also be transmitted from the device to a central control server or other device via the neutral API mechanism disclosed herein. The neutral API mechanism can be used to transmit information including, but not limited to: service status; API module startup and response; website hosting; database operation; security - whether the SSL certificate for HTTPS communication is up to date; whether the components of the geographic destination are running.

[0127] The information exchange via a neutral API may have other uses related to security / firewall / monitoring / collaboration / information exchange and other mission-critical aspects of a network environment such as a GVN.

[0128] A neutral API mechanism could be a powerful medium for information exchange, thus enabling the deployment of comprehensive self-healing across devices.

[0129] Figure 8 The information flow between the device and the central control server according to an embodiment of the present invention is shown. This example embodiment describes the information flow between the devices of the global virtual network. The central repository composed of the database B200 and the file storage HFS200 can be coupled to the central control server (SRV_CNTRL) 200. In some embodiments, the central repository can store API / action information. For example, the central repository can store the definition of the API / action, the script associated with the API / action that can be used to process the API / action. In some embodiments, the central repository can also store the peer relationship of the device.

[0130] P100200 / P100300 / P1008500 / P200100 / P200300 / P2008500 / P8500200 / P3008500 represent the communication between GVN devices that have a peer pair and thus have a priority relationship with each other. EPD 100 / SRV_AP 300 / other devices 8500 may be coupled with file storage HFS100 / HFS300 / HFS8500 and database B100 / B300 / B8500.

[0131] The figure shows peer pair communications in a round-robin mode from SRV_CNTRL 200 to EPD 100 via P200100, from SRV_CNTRL 200 to SRV_AP 300 via P200100, or from SRV_CNTRL 200 to other devices 8500 via P2008500. EPD 100 communicates with SRV_CNTRL 200 via P100200, with SRV_AP 300 via P300200, and with other devices 8500 via P8500200.

[0132] In some cases, there may be an information sharing loop between devices, for example, EPD100 may request information from SRV_CNTRL200 via P100200, and the request will be sent back to EPD100 via P200100.

[0133] In other cases, one device may report information related to other devices, for example, SRV_AP300 reports to SRV_CNTRL200 via P300200 , and SRV_CNTRL200 then sends the information to EPD100 via P200100 , or sends the information to other devices 8500 via P2003001 .

[0134] In other cases, sending log information from a device may not require a complete loop, for example, EPD100 sends information to SRV_CNTRL200 via P100200, and there is no need to forward this information further. However, the logging information may then be moved from the repository on SRV_CNTRL200 to other devices 8500 via P2008500.

[0135] There is a direct link P100300 between the device EPD100 and SRV_AP300. There is a direct link P3008500 from SRV_AP300 to other devices 8500. Direct links involve communication between devices that do not require the participation of SRV_CNTRL.

[0136] The push information 8306 from the SRV_CNTRL 200 may be an RSS feed or other type of information published via P8306. The API query 8302 from the SRV_CNTRL 200 may be a traditional API transaction or a RESTful API call that issues a request via P8302REQ and receives a response via P8302RESP. The push 8306 and API query 8302 are provided to illustrate devices that do not share peer pair relationships, action codes or definitions (e.g., action codes and / or definitions are not obtained, action codes and / or definitions are outdated), priority states, and / or similar system architectures with GVN devices.

[0137] Fig. 9 A Backbone Switch Server (SRV_MX) topology with security and open API sequence according to an embodiment of the present invention is shown.This example embodiment illustrates a series of API calls in sequence within an exemplary device topology within a typical global virtual network.

[0138] The first API call request 9A1 from the access point server SRV_AP300 to the central control server SRV_CNTRL200 is received, parsed and processed by SRV_CNTRL200. It then triggers three more API calls, all initiated by SRV_CNTRL200. Depending on the nature of the communication, these can be processed sequentially or can be processed simultaneously in parallel. The three additional calls are a request 9A2 sent to the backbone switching server SRV_BBX9800 and a response 9A3 sent back, a request 9A4 sent to another SRV_BBX9810 and its response 9A5, and finally a third additional API call of request 9A6 sent to SRV_AP9302 and a response 9A7 sent back to SRV_CNTRL200. When all three of these "internal" calls are completed, the final response 9A8 is returned to SRV_AP300, the device that initiated the first request 9A1.

[0139] The API request 9A1 and response 9A8 may be characterized as an open ended call with the following requirements: The call may not be complete until internal calls 9A2-9A3 involving SRV_BBX9800, 9A4-9A5 involving SRV_BBX9810, and 9A6-9A7 involving SRV_AP9302 are completed. This may be because SRV_AP300 requires information before subsequent actions can be taken, for measurement and integration purposes, or other reasons. For example, if an end-to-end tunnel is to be established from SRV_AP300 via SRV_BBX9800 to SRV_BBX9810 to SRV_AP9302 via a path 9P2 to 9P3 to 9P8, all of these devices may need to be configured or triggered with the appropriate information and details. This type of API call can make this setup request to SRV_CNTRL200 via 9A1, and then through three internal API calls 9A2-9A3, 9A4-9A5, 9A6-A97, and the response 9A8 can include both configuration and setup information for use by SRV_AP300 and setup and preparation instructions from SRV_CNTRL200 about other peer devices.

[0140] Fig. 9 Includes EIP 9500 connecting to the open Internet 9700 via 9P5, POP 9600 and 9P6. Fig. 9 Includes EIP 9502 connected to EIP 9502 open Internet 9702 via 9P10, POP 9602, and 9P11. 9P1 connects EPD 100 and SRV_AP300. 9P4 connects SRV_AP 300 and EIP9500. 9P7 connects EPD 9102 and SRV_AP 9302. 9P9 connects SRV_AP and EIP9502.

[0141] In some embodiments, A2 / A3 and A4 / A5 and A6 / A7 are independent API calls arranged in series / sequentially. In other embodiments, A2 / A3 and A4 / A5 and A6 / A7 can be executed in parallel.

[0142] Security elements can be placed in multiple locations in the GVN topology shown in this article. For example, firewalls FW9400 and FW9402 may be placed along 9P2 and 9P8. Firewalls FW9400 and FWM02 can protect SRV_BBX from Internet threats, thereby ensuring secure backbone communications.

[0143] Information about secure exit and entry points (EIP 9500 and 9502) may also be a factor in such API exchanges.

[0144] Fig.10The open API call that relies on the internal API call completion according to an embodiment of the present invention is shown. Fig. 9 and can provide different perspectives of a set of API calls between GVN devices in the global virtual network GVN and the central control server SRV_CNTRL 200. The open-ended call bookend API#1 (9A1-9A8) encapsulates and includes internal API calls API#2 (9A2-9A3), API#3 (9A4-9A5) and API#4 (9A6-9A7).

[0145] The three inner round trips are dependencies required for the outer round trip to be complete. The response from API#1 (9A8) will wait for the inner API calls API#2 (9A2_9A3), API#3 (9A4-9A5), and API#4 (9A6-9A7) to complete before the results can be evaluated and sent back as a response. Only at this point can the open API be closed and the response sent.

[0146] This type of sequence is similar to a transaction set of SQL statements. All tasks must be completed, otherwise they cannot be completed. Therefore, if one of the calls fails, a rollback can also be performed.

[0147] Fig.11 Requests / responses between peer devices and between devices and a central control server according to an embodiment of the present invention are shown. This example embodiment illustrates two types of device-to-device information exchange via a neutral API mechanism. More specifically, Fig.11 Two types of neutral API mechanism requests REQ / responses RESP are illustrated that are POSTed (triggered) in a closed loop between a known pair of peers via 11-A and 11-B.

[0148] In some embodiments, device-to-repository call / information exchange 11-A means that SRV_CNTRL200 can operate in repository mode to an API peer such as EPD100 (via 11req100200 / 11resp100200) or SRV_AP300 (via 11req300200 / 11resp300200) or other device to query information about: the device itself (e.g., a list of device peers); the device's peer partners (e.g., information of peer devices); API mechanisms (e.g., actions-action codes, associated handlers, scripts, payload structures, etc., scripts associated with actions, definitions / structures of actions, etc.).

[0149] In some embodiments, SRV_CNTRL 200 can operate in multiple modes, including repository (for peers to query), peer initiator (client), peer target (server).

[0150] For example, when a peer relationship exists between devices, the devices can communicate directly with each other using device-to-device information exchange 11-B (via 11req100300 / 11resp100200), where each device has information about the other device, which may include security keys, tunnel information, port and IP address information, etc.

[0151] Depending on the dynamic settings of the peer, all devices can act as clients initiating requests, servers actively listening for requests and providing responses, or both.

[0152] Fig.12 The closed loop and the open loop according to the embodiment of the present invention are shown. Fig.11 ,and Fig.11 All elements are included in Fig.12 In. With Fig.11 The closed loop shown is different. Fig.12 Further shown in FIG. 12 is a RESTful URL POST (trigger) that may be performed to all unknown peers in an open access architecture (if this particular action is dynamically allowed) via a query 12R200 made to SRV_CNTRL 200 through a request REQ 12R200 and a response RESP 12R200. For example, a device may use the URL http / / path.to / cntrl / time / check to receive the current time. The response will echo the content provided by the path, and the response may be plain text, an array or key-value pair, or an encapsulated array or other data representation.

[0153] Query 12R100 (via REQ12R100 and corresponding RESP12R100 ) can represent a RESTful URL call to EPD100 .

[0154] Query 12R300 (via REQ12R300 and corresponding RESP12R300 ) can describe a RESTful URL call to SRV_AP 300 .

[0155] In some embodiments, the neutral API may have multiple access points, such as close only, open only via URL, and close and open via URL.

[0156] In some embodiments, authentication may be required for an open and / or closed neutral API mechanism. In other embodiments, authentication may not be required for an open and / or closed neutral API mechanism.

[0157] In some embodiments, for a RESTful neutral API request / response, it may be possible to provide information by simply opening the URL address, or it may be necessary to POST (trigger) the information as part of the request query before any information can be provided. For example, when querying for time, SRV_CNTRL200 will only return the time if a valid device ID of the requesting device is provided in the POST (trigger) of the URL data. Otherwise, an error may be returned, and a message that the device is unknown may be returned, or no message or content may be returned.

[0158] Fig.13 An exemplary transaction code in a request payload according to an embodiment of the present invention is shown. This exemplary embodiment illustrates an exemplary transaction code structure of a request made by a client to a server within a neutral API mechanism.

[0159] In some embodiments, client data 13-A includes TRC100, TRC200, and TRC300. Server data 13-B includes TRC500. Request transaction code sequence 13-REQ includes 13-A and 13-B. Device_code TRC100 refers to the identifier of the client. Date_code TRC200 can be calculated and can be based on the current UNIX timestamp (seconds from UNIX time or POSIX time). Transaction_code TRC300 is based on the universal unique identifier (UUID) code of the sequentially arranged API call records made by the client. Device_code TRC500 refers to the target / destination device UUID of the server. These values ​​can be separated by a hyphen "-", enclosed in square brackets, or otherwise encapsulated to indicate their values. For all codes, the integer value of the device or time or transaction, its associated name, and or similar to the Base-36 conversion of the integer, or other representations of data can be used.

[0160] The request transaction code sequence 13-REQ may be used in whole or in part to identify a peer pair, record a transaction number, be used as part of an encryption / decryption process, or for other purposes.

[0161] Fig.14 An exemplary transaction code in a response payload according to an embodiment of the present invention is shown.

[0162] This example embodiment illustrates the transaction code structure of the response 14-RESP returned by the server to the client within the Neutral API Mechanism (NAPIM). Based on the sequentially arranged API call record replied by the peer (server) in the form of 14-RESP, it includes the original request transaction code TRC100 / TRC200 / TRC300 / TRC500 as the base value, and the additional date code TRC600 of the response and the transaction code TRC700 Universal Unique Identifier (UUID) code are attached. Fig.14 As shown, the response transaction code sequence 14-RESP includes client data 13-A and server data 14-B. The client data 13-A includes TRC100 / TRC200 / TRC300. The server data 14-B includes TRC500 / TRC600 / TRC700.

[0163] Upon receipt by the client, the client can confirm the authenticity of the received 14-RESP using the original TRC100, TRC200, TRC300, and TRC500 elements, and can use these elements to match this information with the original request. The client can also record the TRC600 and TRC700 elements to record the response details for verification purposes.

[0164] The response transaction code sequence 14-RESP may be used in whole or in part to identify a peer pair, record a transaction number, be used as part of an encryption / decryption process, or for other purposes.

[0165] Fig.15 An exemplary element mapping in a request / response payload in a closed loop according to an embodiment of the present invention is shown. This exemplary embodiment illustrates the relationship between the action-code in the external payload and the action-code-extension in the internal payload. It also maps some action code elements of multiple steps in the API sequence in the neutral API mechanism to action code / action code-extension items. These scripts, databases, and action items appear in three stages: on the source peer in stage STR1 (before POST (trigger)), on the destination peer in stage STR2 (after receiving the REQ of POST (trigger)), and on the source peer in stage STR-3 (after receiving the POST (trigger) of return RESP).

[0166] like Fig.15 As shown, in some embodiments, the REQ Mech012 / RESP Mech022 of the API call is performed between known peers and related peers via the security framework of the neutral API mechanism. NAPIM-operation Mech1 00 includes Mech012 (via Mech010) and Mech022 (via Mech010).

[0167] The action-code is a generic short form included in the outer payload AC-0. The action-code-extension is the inner longer form securely enclosed in the encrypted inner payload AC-I. These codes must correlate to each other when decrypting the inner payload from the outer payload, and if they do not, it could be a man-in-the-middle (MITM) attack), a replay attack, or other issues that would render the sequence of API calls invalid. This is for operational and security reasons.

[0168] On the source peer of phase STR1 (before POST (trigger)), the payload REQ generator script STR1-02, the structure of the inner payload AC-I for this specific action, will be prepared, filled and then encrypted into the outer payload AC-0.

[0169] Also on the source peer of stage STR1 (before POST (trigger)), the database of REQ payload structure definitions stores payload definition STR1-04, i.e., the definition of the internal payload AC-I structure of this specific action will be defined in this article as being associated with this specific action. This can help create the payload, check its validity, parse it, and implement other functions of the API call.

[0170] In step NAPIM-REQ POST (trigger) Mech012, a REQ POST (trigger) is performed from the client to the listening server peer.

[0171] On the target peer at STR2 (after receiving the REQ of the POST (trigger)): script STR2-02 parses PL-01-OUTER as a POST (trigger) parser (processing the request is included in the general parser) - the general parser may include an auxiliary parser based on the action code in the external payload AC-0; the PL01-internal database storage payload definition STR2-04 can be used to parse the PL01-internal script STR2-06 to process the action to be taken (in some embodiments, STR2-06 can retrieve or execute supporting files, supporting modules and / or supporting classes / functions); recorder STR2-08 records (records around actions and / or action descriptions and / or records actions); script STR2-10 generates a response RESP payload PL02-external from PL02-internal (based on the action); the RESP payload structure PL02-internal definition (based on the action) database storage payload definition STR2-12 can be used to create PL02-internal.

[0172] In step NAPIM-RESP POST (Trigger) Mech022, a RESPP0ST (Trigger) is sent back from the server peer to the original client peer.

[0173] On the source peer in stage STR3 (after receiving the POST (trigger) that returns RESP): script STR3-02 acts as a POST (trigger) parser to parse PL02-external and separate out PL02-internal (processing RESP included in the general parser); the REQ / RESP combined payload structure definition STR3-04 stored in the database can be used to parse PL02-internal; script 3-06 processes the actions included in RESP PL02-internal; recorder STR3-08 performs logging; script 3-10 checks whether it is necessary to trigger the addition of a new API call; script STR3-12 handles the closing, completion, cleanup, reporting, etc. of this API sequence.

[0174] The scripts, data storage payload definitions, actions to be taken within the defined action code, and other action code elements in the neutral API mechanism exemplified above can be used together with other elements to perform a variety of different actions through a neutral API mechanism framework.

[0175] Fig.16 An exemplary element mapping in a request / response payload in an open / RESTful loop according to an embodiment of the present invention is shown. This exemplary embodiment illustrates a variable mapping extracted from an action-URL-variable AC-P mapping to an action-code-open AC-U to utilize an action associated with a URL variable. This is one aspect of implementing a neutral API mechanism for an open URL RESTful query.

[0176] NAPIM-operation Mech200 includes Mech212 (via Mech210) that parses the request path POST (trigger) and sends back a response Mech222 (via Mech220). The URL request is parsed via Mech212 to extract variables from the URL. The action-URL-variables are evaluated to find the action-code-open-AC associated with a known action.

[0177] In some embodiments, the URL listener and path resolver STR5 include the following elements: script STR5-02 acts as a path resolver to identify the action-URL-variable in the path variable POSTed (triggered); the database of action-code-open structure definition (based on action) STR5-04 stored in the database can be used for parsing; script STR5-06 processes the action; recorder STR5_08 performs logging; script STR5-10 prepares the content to be posted back (based on each action); script STR5-14 handles the closing, completion, cleanup, reporting, etc. of this RESTFulAPI sequence; script STR5-16 checks whether there is a 0n-X-Trigger (trigger on X) hook point in the variable POSTed (triggered) on the URL path.

[0178] The above elements of STR5 can be used to process RESTful open requests mapped to defined actions in the neutral API mechanism. Not all are required, and other elements not shown in this example embodiment can also be used for one, more or all actions. The results can be sent back via Mech222.

[0179] In some embodiments, not every action is accessible via an open / RESTful API call. This is dynamically defined on a per-action basis and may also depend on or be dependent on many factors, including possible requirements for variables that are POSTed (triggered) in addition to the variables collected from the original URL path request.

[0180] Figure 17 shows the collaboration and relationship between the main modules used by the neutral API mechanism according to an embodiment of the present invention. This example embodiment illustrates the core modules of the neutral API mechanism, including the relevant paths for communication between devices.

[0181] The devices shown are an endpoint device EPD 100, a central control server SRV_CNTRL 200, and an access point server SRV_AP 300. Other device types may also participate in the NAP top and communicate with each other.

[0182] In some embodiments, an information repository is provided on each peer device, such as the information repository DW3 on EPD100 and the information repository D393 on SRV_AP300. Each information repository may have an associated database, such as B193 of D193 and B393 of D393. All devices may receive update information of their local information repository from the central information repository D293 on SRV_CNTRL200 via API calls or other information transfer methods. The central repository D293 may have an associated database B293. The information repository D193 / D293 / D393 may store API / action information, including but not limited to scripts related to actions, definitions related to actions, availability of actions (e.g., via a flag indicating availability), and rejection of actions (e.g., via a flag indicating that an action is rejected). Definitions may enable the creation and parsing of action payloads (e.g., response payloads and request payloads).

[0183] In some embodiments, the device managers D191, D291, and D391 may store information in databases B191, B291, and B391, etc., so that the device has information about itself. This may be performed locally at device setup or during the life cycle of the device, or performed or updated via API calls to / from SRV_CNTRL200.

[0184] In some embodiments, each device may have a NAPIM manager, such as D192 on EPD 100, D392 on SRV_AP 300, and D292 on SRV_CNTRL 200. These managers handle the operation of the NAPIM components.

[0185] In some embodiments, API action code, scripts, classes, definitions, and other supporting methods are managed by the NAPIM manager, including ensuring that mechanisms are up to date, dependencies are in place, and other elements are valid, thereby ensuring the smooth operation of NAPIM.

[0186] In some embodiments, updates from the device to the SRV_CNTRL 200 are performed via PAl or PA2 or other direct P-2-CNTRL routing or calls. These can be initiated from either end.

[0187] In some embodiments, the communication path of TP01 to TP02 via CP03 may represent a tunnel that pushes traffic between EPD 100 and SRV_AP 300. It may also represent other types of communications and / or device interactions.

[0188] In some embodiments, path CP02 may represent a direct tunnel between devices, an API call in either direction, or other types of communications between EPD 100 and SRV_AP 300 .

[0189] The above nine points are examples of possibilities. There may be others. The key point is that by combining the rigid external architecture of a neutral API mechanism, POST (trigger), listen, process, and other aspects with an almost unlimited number of dynamically updateable actions, incredible flexibility can be achieved while safely automating and simplifying many aspects of the API architecture and peer relationships in this article.

[0190] The scope of the present invention is not limited to the specific embodiments described herein. In fact, in addition to the contents described herein, those of ordinary skill in the art can clearly understand other multiple embodiments of the present invention and modifications to the present invention from the above description and the accompanying drawings. Therefore, such other embodiments and modifications are all within the scope of the present invention. In addition, although the present invention has been described in the context of at least one specific embodiment in at least one specific environment for at least one specific purpose, those of ordinary skill in the art will recognize that its usefulness is not limited thereto, and the present invention can be beneficially implemented in any number of environments for any number of purposes. Therefore, the appended claims should be interpreted according to the complete breadth and spirit of the present invention as described herein.

[0191] According to an embodiment of the present disclosure, the following additional notes are also disclosed:

[0192] 1. A system for a neutral application programming interface, comprising:

[0193] A device configured to:

[0194] receiving a request, wherein the request includes an outer payload and an inner payload;

[0195] parsing the external payload based on a common definition of the external payload;

[0196] extracting information of the action from the external payload;

[0197] parsing the inner payload based on a definition of the action;

[0198] and processing the action.

[0199] 2. A system according to Note 1, wherein the external payload includes a timestamp of the time when the request was generated.

[0200] 3. A system according to Note 2, wherein the internal payload is encrypted and the device is further configured to decrypt the internal payload.

[0201] 4. A system according to Note 2, wherein the device is configured not to process the action if the time interval between the time when the device receives the request and the timestamp exceeds a threshold.

[0202] 5. A system according to Note 4, wherein the threshold is based on network latency.

[0203] 6. A system according to Note 4, wherein the threshold is equal to 1 second.

[0204] 7. A system according to Note 3, wherein the encryption of the internal payload is based on the timestamp and the action.

[0205] 8. A system according to Note 7, wherein the encryption of the internal payload is also based on an initiating device that initiates the request and the device.

[0206] 9. The system according to Note 1, wherein the request is transmitted via a secure socket layer.

[0207] 10. A system according to Note 1, wherein the internal payload includes at least one of an array, a key-value pair, an object, a data file, and a binary file.

[0208] 11. The system according to Note 1, wherein the device is further configured to process the action using a script.

[0209] 12. The system according to Note 11, wherein the device is further configured to retrieve the action from a server.

[0210] 13. The system according to Note 12, wherein the server is configured to: store information about actions; and store information about devices.

[0211] 14. The system according to Note 13, wherein the server is further configured to store a peer-to-peer relationship between the initiating device and the destination device.

[0212] 15. The system according to Note 13, wherein the server is further configured to update the action.

[0213] 16. The system according to Note 14, wherein the device is further configured to retrieve its own peer initiating device list from the server; and listen to requests from devices in its own peer initiating device list.

[0214] 17. The system according to Note 13, wherein the server is further configured to push the action to the device.

[0215] 18. The system according to Note 13, wherein the server is further configured to mark actions to indicate availability.

[0216] 19. The system according to Note 1, wherein the device is further configured to: send a response to the request.

[0217] 20. The system according to Note 19, wherein the device is further configured to include a portion of the request in the response.

[0218] 21. A method for a neutral application programming interface, comprising:

[0219] receiving a request, wherein the request includes an outer payload and an inner payload;

[0220] parsing the external payload based on a common definition of the external payload;

[0221] extracting information of the action from the external payload;

[0222] Parsing the inner payload based on a definition of the action; and processing the action.

[0223] 22. A method according to Note 21, wherein the external payload includes a timestamp of the time when the request was generated.

[0224] 23. The method according to Note 22, wherein the internal payload is encrypted, and the method further comprises decrypting the internal payload.

[0225] 24. The method according to Note 22, wherein if the time interval between the time when the device receives the request and the timestamp exceeds a threshold, the action is not processed.

[0226] 25. The method of claim 24, wherein the threshold is based on network delay.

[0227] 26. The method according to Note 24, wherein the threshold is equal to 1 second.

[0228] 27. A method according to Note 23, wherein the encryption of the internal payload is based on the timestamp and the action.

[0229] 28. The method according to Note 27, wherein the encryption of the internal payload is also based on an initiating device that initiates the request and a device that receives the request.

[0230] 29. The method according to Note 21, wherein the request is transmitted via a secure socket layer.

[0231] 30. The method according to Note 21, wherein the internal payload includes at least one of an array, a key-value pair, an object, a data file, and a binary file.

[0232] 31. The method according to Note 21 also includes using a script to process the action.

[0233] 32. The method according to Note 21 also includes retrieving the action from a server.

[0234] 33. The method according to Note 22 further includes: storing information about actions through the server; and storing information about devices through the server.

[0235] 34. The method according to Note 33 also includes: storing the peer relationship between the initiating device and the destination device through the server.

[0236] 35. The method according to Note 33 also includes: updating the action through the server.

[0237] 36. The method according to Note 34 further includes: retrieving a list of peer initiating devices from the server; and listening to requests from devices in the list of peer initiating devices.

[0238] 37. The method according to Note 33 also includes: pushing actions to the device through the server.

[0239] 38. The method according to Note 33 also includes: marking actions by the server to indicate availability.

[0240] 39. The method according to Note 21 also includes: sending a response to the request.

[0241] 40. The method according to Note 39 also includes: including a portion of the request in the response.

[0242] 41. A non-transitory computer-readable medium storing a computer-readable program of a neutral application programming interface, the non-transitory computer-readable medium comprising: computer-readable instructions for receiving a request, wherein the request comprises an external payload and an internal payload; computer-readable instructions for parsing the external payload based on a general definition of the external payload; computer-readable instructions for extracting information of an action from the external payload; computer-readable instructions for parsing the internal payload based on a definition of the action; and computer-readable instructions for processing the action.

[0243] 42. The system according to Note 1, wherein the device is further configured to add the action to a queue.

[0244] 43. A system according to Note 1, wherein the device is further configured to record the request and the action.

[0245] 44. The method according to Note 21 also includes: adding the action to a queue for processing.

[0246] 45. The method according to Note 21 also includes: recording the request and the action.

[0247] 46. ​​A system for a neutral application programming interface, comprising: a device, wherein the device is configured to: generate an internal payload including an action based on a definition of the action; generate an external payload based on a common definition of the external payload; generate a request including the external payload and the internal payload; and send the request.

Claims

1. A system for a neutral application programming interface, comprising: A first device configured to: create a request inner payload based on a definition of an API action, prepare a request outer payload, and issue an API request, wherein the request inner payload is carried in the request outer payload and the request outer payload follows a common definition; A second device is configured to: In response to receiving the API request, parsing the request external payload based on the common definition of the request external payload; Extracting information of the API action from the request external payload; Parsing the request internal payload based on the definition of the API action; Processing the API action; and After processing the API action, creating a response inner payload based on the request inner payload, preparing a response outer payload, and issuing an API response; The first device is further configured to: in response to receiving the API response, compare the request inner payload with the received response outer payload to verify security.

2. The system according to claim 1, wherein: The first device is further configured to: Execute the API action corresponding to the response internal payload.

3. The system according to claim 1, wherein: The request inner payload and the response inner payload are encrypted, and one or both of the first device and the second device are further configured to decrypt the request inner payload and the response inner payload.

4. The system according to claim 3, wherein: The encryption is based on the API action and a timestamp indicating the time when the API request was generated.

5. The system according to claim 4, wherein: The encryption is also based on the first device and the second device.

6. The system according to claim 1, wherein: The first device and the second device are further configured to process the API action using a script.

7. The system of claim 1, further comprising: A server is configured to store information about API actions and information about the first device and the second device, wherein the second device is further configured to retrieve the API actions from the server.

8. The system according to claim 7, wherein: The server is further configured to store a peer relationship between the first device and the second device.

9. The system according to claim 7, wherein: The server is also configured for updating API actions.

10. The system according to claim 1, wherein: The second device is also configured to queue the API action for processing.

11. A method for a neutral application programming interface, applied to a first device, comprising: Creating a request inner payload based on a definition of an API action, preparing a request outer payload, and issuing an API request, wherein the request inner payload is carried in the request outer payload and the request outer payload follows a common definition; In response to receiving an API response, comparing the request inner payload with the received response outer payload to verify security, wherein the API response is issued by the second device that receives the API request after performing the following actions: In response to receiving the API request, parsing the request external payload based on the common definition of the request external payload; Extracting information of the API action from the request external payload; Parsing the request internal payload based on the definition of the API action; Processing the API action; and A response inner payload is created based on the request inner payload, and a response outer payload is prepared.

12. The method according to claim 11, further comprising: Execute the API action corresponding to the response internal payload.

13. The method according to claim 12, wherein: Use the script to execute the API action corresponding to the internal payload of the response.

14. A system for executing an application programming interface call, comprising: A first server is configured to: Send the first API request, Create the request internal payload based on the definition of the API action, and preparing a request external payload and issuing the first API request, wherein the request internal payload is carried in the request external payload and the request external payload follows a common definition; The central control server is configured to: In response to receiving the first API request, parsing the request external payload based on the common definition of the request external payload, Extract information about the API action from the request external payload, Parsing the request internal payload based on the definition of the API action, Process the API action, sending a second API request to one or more second servers, and After receiving an API response from each of the one or more second servers, a corresponding API response is sent to the first server.

15. The system of claim 14, wherein: The one or more second servers include at least one of one or more backbone switching servers and access point servers.

16. The system according to claim 14 or 15, wherein: The number of the one or more second servers is plural, and sending the second API requests to the one or more second servers is performed sequentially or in parallel.

17. The system according to claim 14 or 15, wherein: If no API response is received from any of the second servers, the transaction is rolled back.

Images