CN111125642B

CN111125642B - Method and device for managing API, storage medium and computer equipment

Info

Publication number: CN111125642B
Application number: CN201811290634.XA
Authority: CN
Inventors: 易榜宇; 张万军; 万振; 赵鹏
Original assignee: Beijing Shuju Xinyun Information Technology Co ltd
Current assignee: Beijing Shuju Xinyun Information Technology Co ltd
Priority date: 2018-10-31
Filing date: 2018-10-31
Publication date: 2022-06-03
Anticipated expiration: 2038-10-31
Also published as: CN111125642A

Abstract

The invention discloses a method and a device for managing an API (application program interface), a storage medium and computer equipment. The disclosed method comprises: managing the use authority of each API based on the item and/or the API set; the usage rights of individual APIs in an item and/or API collection are managed on a single API basis as the usage rights of the individual APIs change. The technical scheme disclosed is more flexible in configuration mode when the use authority of the API is managed.

Description

Method and device for managing API, storage medium and computer equipment

Technical Field

The present invention relates to the field of computer and software engineering, and in particular, to a method, an apparatus, a storage medium, and a computer device for managing an API.

Background

In the field of computer and software engineering, various APIs are often used, and different usage rights may need to be set for different APIs to ensure security and the like.

When performing API (e.g., webAPI used by internet services) management, the following methods are generally adopted:

1. the method is based on API set-API strategy, namely, a user can configure a strategy message and then apply the strategy message to the whole API set, thereby realizing one-time configuration of the group of APIs.

2. The way of project-API policy based, i.e. one or more APIs under a project, now allows to add policies to the project, and after adding a common policy to the project, the APIs under the project inherit the policy configuration information of the project by default.

The disadvantage of both approaches is that after the API policy information is modified, the configuration information for all APIs in the API set and/or project changes accordingly.

Therefore, in the actual API management process, when configuration information of several special APIs in an API set and/or project needs to be modified individually, it is very inconvenient in the face of complicated and cumbersome API configuration requirements because all the APIs need to be disconnected even if policy management of individual APIs needs to be changed, thereby affecting the calling policies of other APIs.

In addition, a "total package situation" may be encountered when the webAPI is managed, for example, the limitation on the "number of invocations per unit time" may be not only for one API, but for one item, that is, the sum of the number of invocations per unit time of all APIs in the item cannot exceed the predetermined total number of invocations per unit time set for the item. In this case, the above two methods of the prior art cannot be used for management.

Third, the above API management methods adopted in the prior art do not consider specific security policy settings, for example, do not consider setting different security levels for the API.

That is, in the API management policy model in the prior art, adding policies is mainly adopted, and managing APIs is implemented in a manner of binding APIs for corresponding policies, which is too rigid and inflexible. In addition, it is difficult to meet the complicated and complicated API configuration requirements, such as the above-mentioned "total package case". Thirdly, the security is poor. Therefore, new technical solutions are needed to solve the above problems.

Disclosure of Invention

The method for managing the API comprises the following steps:

managing the use authority of each API based on the item and/or the API set;

the usage rights of individual APIs in an item and/or API set are managed on a single API basis as the usage rights of the individual APIs change.

The method for managing the API further comprises the following steps:

in managing the usage rights of the respective APIs on a project basis, the usage rights of all APIs under a specified project are managed using the overall criterion.

The method for managing the API further comprises the following steps:

when the use permission of each API is managed based on the item and/or the API set, establishing a mapping relation between the item and/or the API set and address information used for storing specific management strategy information so as to manage the use permission of each API;

when the usage rights of the individual APIs are managed based on a single API, a mapping relationship is established between the single API and specific policy information to manage the usage rights of the single API.

According to the method for managing the API, the general criteria comprise: the total number of times that all APIs under a given project are called per unit time does not exceed the predetermined total number of times that all APIs under a given project are called per unit time.

The device for managing the API comprises the following components:

the first management module is used for managing the use permission of each API based on the item and/or the API set;

and the second management module is used for managing the use permission of the individual API based on the single API when the use permission of the individual API in the item and/or the API set is changed.

The apparatus for managing API according to the present invention further comprises:

and the third management module is used for managing the use permission of all the APIs under the specified project by using the overall criterion when the use permission of each API is managed based on the project.

the fourth management module is used for establishing a mapping relation between the item and/or the API set and address information used for storing specific management strategy information when the use permission of each API is managed based on the item and/or the API set so as to manage the use permission of each API;

and the fifth management module is used for establishing a mapping relation between the single API and the specific policy information to manage the use permission of the single API when the use permission of the individual API is managed based on the single API.

The device for managing the API according to the invention has the general criteria that: the total number of times that all APIs under a given project are called per unit time does not exceed the predetermined total number of times that all APIs under a given project are called per unit time.

According to a storage medium of the invention, a computer program is stored on the storage medium, which program, when being executed by a processor, carries out the steps of the method as described above.

The computer device according to the invention comprises a memory, a processor and a computer program stored on the memory and executable on the processor, the processor implementing the steps of the method described above when executing the program.

According to the technical scheme of the invention, the configuration mode is more flexible when the use authority of the API is managed.

Drawings

The accompanying drawings, which are incorporated in and constitute a part of the specification, illustrate embodiments of the invention and together with the description, serve to explain the principles of the invention. In the drawings, like reference numerals are used to indicate like elements. The drawings in the following description are directed to some, but not all embodiments of the invention. For a person skilled in the art, other figures can be derived from these figures without inventive effort.

Fig. 1 schematically shows a flow chart of a method of managing an API according to the invention.

Fig. 2 schematically shows a block schematic of an arrangement for managing APIs according to the present invention.

Fig. 3 exemplarily shows a schematic diagram for managing usage rights of various APIs based on items and/or API sets, which may be used according to the technical solution of the present invention.

Fig. 4 exemplarily shows a schematic diagram for managing usage rights of individual APIs based on a single API, which may be used according to the technical solution of the present invention.

Detailed Description

In order to make the objects, technical solutions and advantages of the embodiments of the present invention clearer, the technical solutions in the embodiments of the present invention will be clearly and completely described below with reference to the drawings in the embodiments of the present invention, and it is obvious that the described embodiments are some, but not all, embodiments of the present invention. All other embodiments, which can be derived by a person skilled in the art from the embodiments given herein without making any creative effort, shall fall within the protection scope of the present invention. It should be noted that the embodiments and features of the embodiments in the present application may be arbitrarily combined with each other without conflict.

As shown in the solid line box of fig. 1, the method for managing API according to the present invention includes:

step S102: managing the use authority of each API based on the item and/or the API set;

step S104: the usage rights of individual APIs in an item and/or API collection are managed on a single API basis as the usage rights of the individual APIs change.

For example, the following method may be employed to build the API set:

1. the API corresponding to each database or content is collected, and the plurality of APIs are aggregated into one or more API aggregates according to the nature and the role of the API.

For example, the set of APIs may be divided according to specific business content (i.e., data content):

1) the API (1) corresponding to the data content 1, the API (2) corresponding to the data content 2, and the API (n) (n is an integer of 1 or more) corresponding to the data content n of … are divided into a first API set.

2) The other m APIs, i.e., API (m +1) corresponding to data content m +1, API (m +2) corresponding to data content m +2, and API (m + n) (m is an integer of 1 or more) corresponding to … data content m + n are divided into a second API set.

2. The API set may change according to a change in service. That is, the members in the API set may be changed dynamically.

For example, multi-dimensional classification integration can be performed according to an API request path, an API request method, an application scenario in which an API may appear, and the like.

For example, the respective policies may be configured for the APIs of each set according to different needs (i.e., the usage rights of the respective APIs are managed based on the API sets).

Optionally, as shown in the dashed box of fig. 1, the method for managing an API according to the present invention further includes:

step S106: in managing the usage rights of the respective APIs on a project basis, the usage rights of all APIs under a specified project are managed using the overall criterion.

step S108: when the use permission of each API is managed based on the item and/or the API set, establishing a mapping relation between the item and/or the API set and address information used for storing specific management strategy information so as to manage the use permission of each API;

step S110: when managing the use rights of individual APIs based on a single API, a mapping relationship is established between the single API and specific policy information to manage the use rights of the single API.

Alternatively, the above-mentioned general criteria (criteria applicable to "case of total package" in the background art) include: the total number of times that all APIs under a given project are called per unit time does not exceed the predetermined total number of times that all APIs under a given project are called per unit time.

For example, when management configuration is performed based on a project, all APIs under the project inherit configuration information of the project by default, and the principle of the APIs is the same as that of a CSS cascading style sheet, so that batch configuration of the APIs is realized.

For example, the general criteria may be: the total number of times all APIs under the project are called per unit time does not exceed 1000 times/second.

For example, the use configuration information of the individual API under the project may be flexibly modified through step S110.

Fig. 2 schematically shows a block schematic of an apparatus 200 for managing APIs according to the present invention.

Alternatively, as shown in the solid line box of fig. 2, the apparatus 200 for managing APIs according to the present invention includes:

a first management module 201, configured to manage usage rights of each API based on the item and/or API set;

the second management module 203 is used for managing the use right of the individual API based on the single API when the use right of the individual API in the item and/or API set changes.

Optionally, as shown in the dashed box of fig. 2, the apparatus 200 for managing API further includes:

a third management module 205, configured to manage the usage rights of all APIs under the specified project by using the overall criteria when managing the usage rights of each API based on the project.

Optionally, as shown in the dashed box of fig. 2, the apparatus 200 for managing APIs further includes:

a fourth management module 207, configured to establish a mapping relationship between the item and/or the API set and address information for storing specific management policy information when managing the usage right of each API based on the item and/or the API set, so as to manage the usage right of each API;

a fifth management module 209, configured to establish a mapping relationship between the single API and specific policy information when managing the usage rights of the individual APIs based on the single API, so as to manage the usage rights of the single API.

Optionally, the general criteria include: the total number of times that all APIs under a given project are called per unit time does not exceed the predetermined total number of times that all APIs under a given project are called per unit time.

In order to make the technical solutions according to the present invention more clearly understood by those skilled in the art, the following description will be given with reference to specific embodiments.

Fig. 3 exemplarily shows a schematic diagram for managing usage rights of various APIs based on a project and/or API set, which can be used according to the technical solution of the present invention.

Corresponding to the above-mentioned step S108 and the fourth management module 207. As shown in fig. 3, after binding the corresponding policy to the API set and/or the item, the configuration information of the API set or the item stores a policy address, so as to implement association with the policy. When a policy is modified, the configuration information of the API to which the policy is bound is changed accordingly.

As shown in fig. 3, when assigning corresponding policies to each API set (note: the API shown in fig. 3 corresponds to a special case where the number of members in the API set is 1) and each item, each API set and each item correspond to a policy address (i.e., the above address information), and each policy address corresponds to an index.

For example, the API set { API (1), API (2), API (3), API (4) }, and the policy addresses corresponding to API (1) -API (4) are all "xsdaadsdasd" (not shown in fig. 3).

For example, the specific policy configuration information to which the policy address points is the same specific information shown in the right round box in fig. 3.

Alternatively, API (1) -API (4) may correspond to different policy configuration information:

API(1)：{ACL:zhangsan xxxxxxxxxx}

API(2)：{ACL:lisi xxxxxxxxxx}

API(3)：{ACL:wangwu xxxxxxxxxx}

…

Corresponding to step S110 and the fourth management module 209 described above. In order to avoid affecting other APIs when modifying the policy of an individual API, as shown in fig. 4, according to the above technical solution of the present invention, when modifying the policy of an individual API, the association between the individual API and the original policy is broken, and the re-modified configuration information is directly written into the configuration information location of the individual API. That is, the data of the previous storage policy address becomes the direct configuration information, which is similar to the concept of the stack in the memory of the computer, the address information is stored in an object stack, and the real data is stored in the stack. When the data is modified, the connection with the data in the heap needs to be disconnected, when the data is modified independently, the data is changed into a basic type, and new data is directly written into the stack without being associated with any other object.

For example, when the calling policy of the API at the top left corner in fig. 4 is to be changed, only the policy address stored in the API needs to be cleared directly, so that the API has no relation with the old policy, and then the newly modified configuration information (i.e., the specific policy information) is stored directly in the location where the policy address was previously stored, so as to modify the configuration information of one API in the API set.

When the configuration of the individual API is modified, the mapping relation with the original policy is disconnected, and new configuration information (not a policy address) aiming at the individual API is rewritten, so that the individual configuration of the API is realized, and other APIs are not influenced. In addition, because a new strategy does not need to be established and new mapping association is carried out in an index mode, the operation steps are simplified.

Optionally, the policy address information and/or the policy information and/or the call interface information of the API may be stored in the cloud. For example, a change in the API policy address information may override a previous change.

For example, the last used policy information may be stored locally, and the locally stored policy information may be compared with the remote policy information obtained through the cloud policy address information before each invocation to determine whether the policy information has changed.

Optionally, security access level information (e.g., in the form of username + password) may be added to the policy configuration information and/or the directly configured information.

For example, the security access level of a user using the API may be classified into 3 levels (strong, medium, and weak). If a cos { origins: } configuration information is configured in a policy, it indicates that all domains can call the API, and there is no restriction on the request domain, so that the policy can be labeled with a security access level "low", so that when policy binding is performed on some APIs with higher security access level requirements, it is prudent to operate, and the policy cannot be generally assigned to the APIs with higher security access level requirements. That is, APIs of different security access levels may employ different security policies.

Based on the above technical solution according to the present invention, a storage medium is also provided, in which a computer program is stored, and the program, when executed by a processor, implements the steps of the above method.

Based on the above technical solution according to the present invention, a computer device is further provided, which includes a memory, a processor, and a computer program stored in the memory and capable of running on the processor, and when the processor executes the computer program, the steps of the method described above are implemented.

According to the technical scheme of the invention, the method has the following advantages:

1. the strategy can be configured based on the API set and/or the project, and can also be configured based on the API, and the configuration mode is more flexible.

2. When a strategy is applied to a group of APIs, the APIs respectively establish an index to the strategy, and when a single API needs to be independently modified, the strategy is separated (namely the index of the strategy is disconnected), and the real configuration value is independently written into the API configuration, so that the operation steps are simplified.

3. When the project is subjected to policy configuration, the concept of 'total package' is added, so that the API configuration requirement is realized.

4. The security level division similar to a website login password can be added aiming at the direct configuration information of the strategy and/or the API, and the security is improved.

Namely, according to the technical scheme of the invention, batch configuration management of the API and flexible modification of individual special API are realized, and the API is more conveniently managed by a user; the API management function is more complete and stronger, and the management requirements of the API in the actual production environment are more met; compared with a mode of not adopting an API strategy to configure the APIs, each API needs to be configured independently and an independent configuration file is written, and each API does not have any intersection before and has no influence before each other, but batch configuration and batch modification cannot be realized; compared with the mode of completely adopting the API strategy to configure the API, in the API applying a group of strategies, when a certain API is required to be configured and modified independently, a strategy is not required to be newly established, and the modified strategy is bound to the API.

The above-described aspects may be implemented individually or in various combinations, and such variations are within the scope of the present invention.

It will be understood by those of ordinary skill in the art that all or some of the steps of the methods, systems, functional modules/units in the devices disclosed above may be implemented as software, firmware, hardware, and suitable combinations thereof. In a hardware implementation, the division between functional modules/units mentioned in the above description does not necessarily correspond to the division of physical components; for example, one physical component may have multiple functions, or one function or step may be performed by several physical components in cooperation. Some or all of the components may be implemented as software executed by a processor, such as a digital signal processor or microprocessor, or as hardware, or as an integrated circuit, such as an application specific integrated circuit. Such software may be distributed on computer readable media, which may include computer storage media (or non-transitory media) and communication media (or transitory media). The term computer storage media includes volatile and nonvolatile, removable and non-removable media implemented in any method or technology for storage of information such as computer readable instructions, data structures, program modules or other data, as is well known to those of ordinary skill in the art. Computer storage media includes, but is not limited to, RAM, ROM, EEPROM, flash memory or other memory technology, CD-ROM, Digital Versatile Disks (DVD) or other optical disk storage, magnetic cassettes, magnetic tape, magnetic disk storage or other magnetic storage devices, or any other medium which can be used to store the desired information and which can accessed by a computer. In addition, communication media typically embodies computer readable instructions, data structures, program modules or other data in a modulated data signal such as a carrier wave or other transport mechanism and includes any information delivery media as known to those skilled in the art.

Finally, it should be noted that: the above examples are only for illustrating the technical solutions of the present invention, and are not limited thereto. Although the present invention has been described in detail with reference to the foregoing embodiments, it will be understood by those of ordinary skill in the art that: the technical solutions described in the foregoing embodiments may still be modified, or some technical features may be equivalently replaced; and such modifications or substitutions do not depart from the spirit and scope of the corresponding technical solutions of the embodiments of the present invention.

Claims

1. A method of managing APIs, comprising:

managing the use authority of each API based on the item and/or the API set;

managing usage rights for individual APIs in a collection of items and/or APIs based on a single API as the usage rights for the individual APIs change;

when the use permission of the individual API is managed based on a single API, establishing a mapping relation between the single API and specific strategy information so as to manage the use permission of the single API;

when the configuration of the individual API is modified, the mapping relation with the original strategy is disconnected, and new configuration information aiming at the individual API is rewritten.

2. The method for managing APIs of claim 1, further comprising:

3. The method for managing APIs of claim 1, further comprising:

when the use authority of each API is managed based on the item and/or the API set, a mapping relation is established between the item and/or the API set and address information for storing specific management policy information so as to manage the use authority of each API.

4. The method for managing an API of claim 2 wherein said overall criteria comprises: the total number of times that all APIs under a given project are called per unit time does not exceed the predetermined total number of times that all APIs under a given project are called per unit time.

5. An apparatus for managing an API, comprising:

a second management module for managing the use authority of individual API based on a single API when the use authority of the individual API in the item and/or API set changes;

a fifth management module, configured to, when managing usage rights of the individual APIs based on a single API, establish a mapping relationship between the single API and specific policy information to manage the usage rights of the single API;

6. The apparatus for managing an API of claim 5 further comprising:

7. The apparatus for managing an API of claim 5 further comprising:

and the fourth management module is used for establishing a mapping relation between the item and/or the API set and the address information for storing the specific management strategy information when the use permission of each API is managed based on the item and/or the API set so as to manage the use permission of each API.

8. The apparatus for managing an API of claim 6 wherein the overall criteria comprises: the total number of times that all APIs under a given project are called per unit time does not exceed the predetermined total number of times that all APIs under a given project are called per unit time.

9. A storage medium, characterized in that the storage medium has stored thereon a computer program which, when being executed by a processor, carries out the steps of the method according to any one of claims 1 to 4.

10. A computer device comprising a memory, a processor and a computer program stored on the memory and executable on the processor, the processor implementing the steps of the method of any one of claims 1 to 4 when executing the program.