Methods And Systems For Application Program Interface Management
Provided are methods and systems for application program interface (API) management. An API management device may receive requests from client devices to submit an API and/or API update for implementation. The API management device may determine an operable status of the API and/or the API update by determining whether the API and/or the API update is configured and/or updated for implementation. The API and/or the API update may be determined to be configured and/or updated for implementation when the API and/or the API update does not violate one or more rules. The API management device, based on operable status, may allow or deny the request for implementation.
1 . A method comprising:
receiving a request for an implementation device to perform an update to an Application Program Interface (API);
determining, based on the request and an API stability index, a current state of the API; and
causing, based on the current state of the API, performance of the update by the implementation device to be blocked.
2 . The method of claim 1 , wherein the current state of the API comprises an experimental state, and wherein causing performance of the update by the implementation device to be blocked comprises causing the implementation device to deny a code commit comprising the update.
3 . The method of claim 2 , further comprising determining that the current state of the API comprises the experimental state based on at least one of:
determining, based on at least one attribute in the API stability index associated with the API, that the API is under development;
determining, based on the at least one attribute in the API stability index, that the API is operating below a performance threshold; or
determining, based on the at least one attribute in the API stability index, that the API is to be removed, disabled, or deprecated.
4 . The method of claim 1 , wherein the current state of the API comprises a stable state, and wherein causing performance of the update by the implementation device to be blocked comprises causing the implementation device to deny a code commit comprising the update.
5 . The method of claim 4 , further comprising determining that the current state of the API comprises the stable state based on at least one of:
determining, based on at least one attribute in the API stability index associated with the API, a reliability of the API indicative of the stable state;
determining, based on the at least one attribute in the API stability index, that the API is not subject to an API revision; or
determining, based on the at least one attribute in the API stability index, that the API is operating at or above a performance threshold.
6 . The method of claim 1 , wherein the current state of the API comprises a locked state, and wherein causing performance of the update by the implementation device to be blocked comprises causing the implementation device to deny a code commit comprising the update.
7 . The method of claim 6 , further comprising determining that the current state of the API comprises the locked state based on at least one of:
determining, based on at least one attribute in the API stability index associated with the API, a reliability of the API indicative of the locked state; or
determining, based on the at least one attribute in the API stability index, that the API is not subject to an API revision.
8 . An apparatus comprising:
at least one processor; and
memory storing processor-executable instructions that, when executed by the at least one processor, cause the apparatus to:
receive a request for an implementation device to perform an update to an Application Program Interface (API);
determine, based on the request and an API stability index, a current state of the API; and
cause, based on the current state of the API, performance of the update by the implementation device to be blocked.
9 . The apparatus of claim 8 , wherein the current state of the API comprises an experimental state, and wherein the processor-executable instructions that cause the apparatus to cause performance of the update by the implementation device to be blocked further cause the apparatus to cause the implementation device to deny a code commit comprising the update.
10 . The apparatus of claim 9 , wherein the processor-executable instructions that cause the apparatus to determine that the current state of the API comprises the experimental state further cause the apparatus to at least one of:
determining, based on at least one attribute in the API stability index associated with the API, that the API is under development;
determining, based on the at least one attribute in the API stability index, that the API is operating below a performance threshold; or
determining, based on the at least one attribute in the API stability index, that the API is to be removed, disabled, or deprecated.
11 . The apparatus of claim 8 , wherein the current state of the API comprises a stable state, and wherein the processor-executable instructions that cause the apparatus to cause performance of the update by the implementation device to be blocked further cause the apparatus to cause the implementation device to deny a code commit comprising the update.
12 . The apparatus of claim 11 , wherein the processor-executable instructions that cause the apparatus to determine that the current state of the API comprises the stable state further cause the apparatus to at least one of:
determining, based on at least one attribute in the API stability index associated with the API, a reliability of the API indicative of the stable state;
determining, based on the at least one attribute in the API stability index, that the API is not subject to an API revision; or
determining, based on the at least one attribute in the API stability index, that the API is operating at or above a performance threshold.
13 . The apparatus of claim 8 , wherein the current state of the API comprises a locked state, and wherein the processor-executable instructions that cause the apparatus to cause performance of the update by the implementation device to be blocked further cause the apparatus to cause the implementation device to deny a code commit comprising the update.
14 . The apparatus of claim 13 , wherein the processor-executable instructions that cause the apparatus to determine that the current state of the API comprises the locked state further cause the apparatus to at least one of:
determining, based on at least one attribute in the API stability index associated with the API, a reliability of the API indicative of the locked state; or
determining, based on the at least one attribute in the API stability index, that the API is not subject to an API revision.
15 . A system comprising:
an Application Program Interface (API);
a client device;
an implementation device; and
a management device, wherein the management device is configured to:
receive, from the client device, a request for the implementation device to perform an update to the API;
determine, based on the request and an API stability index, a current state of the API; and
cause, based on the current state of the API, performance of the update by the implementation device to be blocked.
16 . The system of claim 15 , wherein the current state of the API comprises an experimental state, and wherein the management device is further configured to cause the implementation device to deny a code commit comprising the update, wherein the code commit is received by the implementation device from the client device.
17 . The system of claim 16 , wherein the management device is configured to determine that the current state of the API comprises the experimental state by:
determining, based on at least one attribute in the API stability index associated with the API, that the API is under development;
determining, based on the at least one attribute in the API stability index, that the API is operating below a performance threshold; or
determining, based on the at least one attribute in the API stability index, that the API is to be removed, disabled, or deprecated.
18 . The system of claim 15 , wherein the current state of the API comprises a stable state, and wherein the management device is further configured to cause the implementation device to deny a code commit comprising the update, wherein the code commit is received by the implementation device from the client device.
19 . The system of claim 18 , wherein the management device is configured to determine that the current state of the API comprises the stable state by:
determining, based on at least one attribute in the API stability index associated with the API, a reliability of the API indicative of the stable state;
determining, based on the at least one attribute in the API stability index, that the API is not subject to an API revision; or
determining, based on the at least one attribute in the API stability index, that the API is operating at or above a performance threshold.
20 . The system of claim 15 , wherein the current state of the API comprises a locked state, and wherein the management device is further configured to cause the implementation device to deny a code commit comprising the update, wherein the code commit is received by the implementation device from the client device.