Automatic discovery of API information
View Patent ↗Automatic discovery of API information is disclosed, including: receiving a transaction; obtaining a determined signature from the transaction; and determining that the determined signature comprises a candidate signature to potentially add to an application programming interface (API) model.
1. A system, comprising:
an external interface configured to exchange information with a client;
an internal interface configured to exchange information with a backend system; and
a processor configured to perform operations comprising:
receiving, at a server and through the external interface, a transaction that is an application programming interface (API) request sent over a network, where the API request includes an indication of an operation type of an operation to be performed and an indication of a path of the operation;
sending the API request to the backend system through the internal interface;
receiving a response to the API request from the backend system through the internal interface;
determining, by the server and from the transaction, a signature that represents a combination of the operation type of the operation to be performed indicated by the API request and the path of the operation indicated by the API request; and
in response to a determination that a combination of the operation type of the operation to be performed and the path of the operation is not found in a classification map associated with an API model, determining whether a status code that is included in the response, received by the server from the backend system, to the API request indicates that the backend system determined that the API request was valid; and
in response to a determination that the status code that is included in the response, received by the server from the backend system, to the API request indicates that the backend system determined that the API request was valid, adding the signature that represents the operation type of the operation and the path of the operation indicated by the API request to the API model;
receiving, at the server and through the external interface, a second transaction that is a second application programming interface (API) request sent over the network;
determining, by the server and from the second transaction, a second signature determined from the second transaction matches the signature added to the API model; and
in response to determining, by the server and from the second transaction, the second signature determined from the second transaction matches the signature added to the API model, applying a run-time policy to the second transaction that is not applied to the transaction that was previously received.
2. The system of claim 1 , wherein the determined signature comprises a set of attributes that identifies the transaction.
3. The system of claim 2 , wherein the set of attributes includes one or more of the following: a resource path pattern, an operation, a header, and a body element.
4. The system of claim 1 , wherein determining that the signature that represents a combination of the operation type of the operation to be performed indicated by the API request and the path of the operation indicated by the API request comprises:
comparing the signature to the classification map, wherein the classification map is determined from the API model;
determining that the signature is not found in the classification map; and
determining that the signature comprises the candidate signature.
5. The system of claim 4 , the operations comprising adding the candidate signature to the API model without user intervention.
6. The system of claim 1 , the operations comprising in the event that the status code comprises a value that indicates that the API request is valid:
presenting the candidate signature at a user interface; and
receiving a user input to add the candidate signature to the API model.
7. The system of claim 1 , the operations comprising in the event that the status code comprises a value that indicates that the API request is valid, adding the candidate signature to the API model without user intervention.
8. The system of claim 1 , the operations comprising in the event that the status code comprises a value that indicates that the API request is invalid, discarding the candidate signature.
9. The system of claim 1 , the operations comprising in the event that the status code comprises a value that indicates that the API request is invalid, determining to potentially add the candidate signature to the API model based at least in part on a stored user configuration.
10. The system of claim 1 , wherein the status code included in the response comprises a hypertext transfer protocol (HTTP) 2xx status code.
11. The system of claim 1 , the operations comprising
updating the classification map in response to the signature determined from the transaction being added to the API model.
12. A computer-implemented method comprising:
receiving, at a server and through an external interface, a transaction that is an application programming interface (API) request sent over a network, where the API request includes an indication of an operation type of an operation to be performed and an indication of a path of the operation:
sending the API request to a backend system through an internal interface;
receiving a response to the API request from the backend system through the internal interface;
determining, by the server and from the transaction, a signature that represents a combination of the operation type of the operation to be performed indicated by the API request and the path of the operation indicated by the API request: and
in response to a determination that a combination of the operation type of the operation to be performed and the path of the operation is not found in a classification map associated with an API model, determining whether a status code that is included in the response, received by the server from the backend system, to the API request indicates that the backend system determined that the API request was valid; and
in response to a determination that the status code that is included in the response, received by the server from the backend system, to the API request indicates that the backend system determined that the API request was valid, adding the signature that represents the operation type of the operation and the path of the operation indicated by the API request to the API model;
receiving, at the server and through the external interface, a second transaction that is a second application programming interface (API) request sent over the network;
determining, by the server and from the second transaction, a second signature determined from the second transaction matches the signature added to the API model; and
in response to determining, by the server and from the second transaction, the second signature determined from the second transaction matches the signature added to the API model, applying a run-time policy to the second transaction that is not applied to the transaction that was previously received.
13. The method of claim 12 , wherein the determined signature comprises a set of attributes that identifies the transaction.
14. The method of claim 13 , wherein the set of attributes includes one or more of the following: a resource path pattern, an operation, a header, and a body element.
15. The method of claim 12 , wherein determining that the signature that represents a combination of the operation type of the operation to be performed indicated by the API request and the path of the operation indicated by the API request comprises:
comparing the signature to the classification map, wherein the classification map is determined from the API model;
determining that the signature is not found in the classification map; and
determining that the signature comprises the candidate signature.
16. The method of claim 15 comprising adding the candidate signature to the API model without user intervention.
17. The method of claim 12 , comprising in the event that the status code comprises a value that indicates that the API request is valid:
presenting the candidate signature at a user interface; and
receiving a user input to add the candidate signature to the API model.
18. A non-transitory computer-readable medium storing software comprising instructions executable by one or more computers which, upon such execution, cause the one or more computers to perform operations comprising:
receiving, at a server and through an external interface, a transaction that is an application programming interface (API) request sent over a network, where the API request includes an indication of an operation type of an operation to be performed and an indication of a path of the operation;
sending the API request to the backend system through the internal interface;
receiving a response to the API request from the backend system through the internal interface;
determining, by the server and from the transaction, a signature that represents a combination of the operation type of the operation to be performed indicated by the API request and the path of the operation indicated by the API request; and
in response to a determination that a combination of the operation type of the operation to be performed and the path of the operation is not found in a classification map associated with an API model, determining whether a status code that is included in the response, received by the server from the backend system, to the API request indicates that the backend system determined that the API request was valid; and
in response to a determination that the status code that is included in the response, received by the server from the backend system, to the API request indicates that the backend system determined that the API request was valid, adding the signature that represents the operation type of the operation and the path of the operation indicated by the API request to the API model;
receiving, at the server and through the external interface, a second transaction that is a second application programming interface (API) request sent over the network;
determining, by the server and from the second transaction, a second signature determined from the second transaction matches the signature added to the API model; and
in response to determining, by the server and from the second transaction, the second signature determined from the second transaction matches the signature added to the API model, applying a run-time policy to the second transaction that is not applied to the transaction that was previously received.