JP2021071929A - Api call handling system and api call handling program - Google Patents

Abstract

To provide a technique for reducing the possibility of interference occurring with operation of an API call handling system itself when use of an API is limited.SOLUTION: In an API call handling system, a front end server 30 comprises a control unit 35 including: a call response unit 35a that returns a response based on data corresponding to an API call; a slot ring execution unit 35b that executes a slot ring on the basis of slot ring information indicating a content of the slot ring as utilization limitation on an API; an API call message enqueue unit 35c that enqueues the API call message into an API call queue for holding the API call message as a message for API call when the API is called; and a slot ring information updating unit 35d that updates the slot ring information based directly or indirectly on API call message held in the API call queue.SELECTED DRAWING: Figure 2

Description

The present invention relates to an API call processing system and an API call processing program that execute processing for an API (Application Program Interface) call.

As a conventional API call processing system, in order to prevent the operation of the API call processing system itself from being hindered by a large number of API calls occurring in a short period of time, new API calls are made according to the number of times the API has been used in the past. Some are known to limit the use of APIs (see, for example, Patent Documents 1 and 2).

Japanese Unexamined Patent Publication No. 2015-05056 Japanese Unexamined Patent Publication No. 2018-097837

However, in the conventional API call processing system, in order to limit the use of a new API, it is necessary to access a table or database that manages the number of times and history of past API use. Therefore, these tables and databases As a result, there is a problem that the operation of the API call processing system itself is hindered.

Therefore, an object of the present invention is to provide an API call processing system and an API call processing program that can reduce the possibility that the operation of the API call processing system itself is hindered when the use of API is restricted. ..

The API call processing system of the present invention has a call response unit that returns a response based on data in response to an API call, and the throttling based on throttling information indicating the content of throttling that is a restriction on the use of the API. The throttling execution unit that executes the above, the API call queue for holding the API call message that is the message for each API call, and the API call message are enqueued to the API call queue when the API is called. It is characterized by including an API call message enqueue unit to be used, and a throttling information update unit that updates the throttling information directly or indirectly based on the API call message held in the API call queue.

With this configuration, the API call processing system of the present invention enqueues an API call message into the API call queue when the API is called, and the slot is directly or indirectly based on the API call message held in the API call queue. Since the ring information is updated, it is not necessary to have a table or database that manages the number of times and history of API usage in the past, and if the API usage is restricted, the operation of the API call processing system itself may be hindered. It can be reduced.

The API call processing system of the present invention includes a throttling instruction queue for holding a throttling instruction message, which is a message instructing the throttling, and a throttling instruction for encuing the throttling instruction message into the throttling instruction queue. The call response unit, the throttling execution unit, the API call message enqueue unit, and the throttling information update unit are realized by a front-end server, and the throttling instruction message enqueue unit is backed up. The throttling instruction message enqueue unit realized by the end server generates the throttling instruction message directly or indirectly based on the API call message held in the API call queue, and the generated throttling instruction. The message may be enqueued to the throttling instruction queue, and the throttling information update unit may update the throttling information based on the throttling instruction message held in the throttling instruction queue.

With this configuration, the API call processing system of the present invention allows the backend server to generate a throttling instruction message based directly or indirectly on the API call message held in the API call queue, based on the throttling instruction message. Because the front-end server updates the throttling information, it limits the use of the API compared to when the front-end server updates the throttling information directly based on the API call messages held in the API call queue. The load on the server can be reduced, and as a result, the possibility that the operation of the API call processing system itself is hindered when the use of the API is restricted can be reduced.

The API call processing system of the present invention includes an aggregation result queue for holding an aggregation result message, which is a message indicating the aggregation result of the number of times the API is called, and an aggregation result that enqueues the aggregation result message into the aggregation result queue. The aggregation result message enqueue unit is realized by the back-end server, and the aggregation result message enqueue unit includes the aggregation result message based on the API call message held in the API call queue. Is generated, the generated aggregation result message is enqueued to the aggregation result queue, and the throttling instruction message enqueue unit generates the throttling instruction message based on the aggregation result message held in the aggregation result queue. Then, the generated throttling instruction message is enqueued to the throttling instruction queue, and the aggregation result message enqueue unit sets the aggregation result message at intervals at which the throttling instruction message enqueue unit generates the throttling instruction message. It may be longer than the generation interval.

With this configuration, the API call processing system of the present invention aggregates at intervals longer than the interval at which the back-end server generates the aggregation result message based on the API call message held in the API call queue and generates the aggregation result message. The back-end server generates a throttling instruction message based on the result message, so it is back compared to when the back-end server generates a throttling instruction message based directly on the API call message held in the API call queue. It is possible to reduce the possibility that a large load is temporarily applied to the end server, and as a result, it is possible to reduce the possibility that the operation of the API call processing system itself is hindered when the use of API is restricted.

The API call processing program of the present invention has a call response unit that returns a response based on data in response to an API call, and the throttling information that indicates the content of throttling that is a restriction on the use of the API. API call message that enqueues the API call message when the API is called in the throttling execution unit that executes the API and the API call queue for holding the API call message that is the message for each API call. It is characterized in that a computer realizes an enqueue unit and a throttling information update unit that updates the throttling information directly or indirectly based on the API call message held in the API call queue.

With this configuration, the computer executing the API call processing program of the present invention enqueues the API call message into the API call queue when the API is called, and directly or indirectly to the API call message held in the API call queue. Since the throttling information is updated based on, it is not necessary to have a table or database that manages the number of times and history of API usage in the past, and when restricting API usage, the operation of the API call processing system itself is hindered. The possibility of occurrence can be reduced.

The API call processing system and the API call processing program of the present invention can reduce the possibility that the operation of the API call processing system itself will be hindered when the use of the API is restricted.

It is a block diagram of the API call processing system which concerns on one Embodiment of this invention. It is a block diagram of the front-end server shown in FIG. 1 in the case of being composed of one computer. It is a figure which shows an example of the throttling information shown in FIG. It is a block diagram of the back-end server shown in FIG. 1 in the case of being composed of one computer. It is a figure which shows an example of the execution condition information shown in FIG. It is a flowchart of the operation of the front-end server shown in FIG. 2 when API is called from the outside. It is a figure which shows an example of the API call message generated in the operation shown in FIG. It is a flowchart of the operation of the back-end server shown in FIG. 4 in the case of totaling the number of API calls during a specific time. It is a figure which shows an example of the aggregation result message generated in the operation shown in FIG. It is a flowchart of the operation of the back-end server shown in FIG. 4 in the case of generating a throttling instruction message. It is a figure which shows an example of the throttling instruction message generated in the operation shown in FIG. It is a flowchart of the operation of the front-end server shown in FIG. 2 when the throttling information is updated.

Hereinafter, embodiments of the present invention will be described with reference to the drawings.

First, the configuration of the API call processing system according to the embodiment of the present invention will be described.

FIG. 1 is a block diagram of the API call processing system 10 according to the present embodiment.

As shown in FIG. 1, the API call processing system 10 collects data from the database 20 and the database 20 in response to an API call from the outside, and returns a response based on the collected data to the outside. And the back-end server 40 that executes processing inside the API call processing system 10, the API call queue 51 for holding a message for each API call (hereinafter referred to as "API call message"), 1 minute, etc. Instructs the aggregation result queue 52 for holding the aggregation result indicating the aggregation result of the number of API calls during a specific time (hereinafter referred to as "aggregation result message"), and throttling, which is a restriction on the use of API. It is provided with a throttling instruction queue 53 for holding a message to be sent (hereinafter referred to as “slotting instruction message”). The API call processing system 10 may be configured by one computer or may be configured by a plurality of computers.

The API call processing system 10 discloses an API to be used from the outside. The API call processing system 10 acquires various information such as the cumulative number of prints, the remaining amount of toner, and the error occurrence status from an image forming apparatus such as an MFP (Multifunction Peripheral) or a dedicated printer that exists in a remote location. It is stored in the database 20. The API call processing system 10 returns, for example, the number of prints of the image forming apparatus in response to an API call from an external system that creates an invoice for the amount of money corresponding to the number of prints of the image forming apparatus, or the image forming apparatus. The remaining amount of toner in the image forming apparatus is returned in response to an API call from an external system that orders toner according to the remaining amount of toner.

FIG. 2 is a block diagram of the front-end server 30 when it is composed of one computer.

As shown in FIG. 2, the front-end server 30 includes an operation unit 31 which is an operation device such as a keyboard and a mouse into which various operations are input, and an LCD (Liquid Crystal Display) which displays various information. Various types of display unit 32, which is a display device, and communication unit 33, which is a communication device that directly communicates with an external device via a network such as a LAN or the Internet, or directly by wire or wirelessly without a network. It includes a storage unit 34, which is a non-volatile storage device such as a semiconductor memory or an HDD (Hard Disk Drive) for storing information, and a control unit 35 that controls the entire front-end server 30.

The storage unit 34 stores the front-end server program 34a, which is a program for the front-end server 30. The front-end server program 34a may be installed on the front-end server 30 at the manufacturing stage of the front-end server 30, for example, a CD (Compact Disk), a DVD (Digital Versaille Disk), or a USB (Universal Serial Bus). It may be additionally installed on the front-end server 30 from an external storage medium such as a memory, or may be additionally installed on the front-end server 30 from the network. The front-end server program 34a constitutes a part of the API call processing program of the present invention.

The storage unit 34 stores throttling information 34b indicating the contents of throttling.

FIG. 3 is a diagram showing an example of throttling information 34b.

As shown in FIG. 3, the throttling information 34b includes a user name as identification information of the caller of the API that is the target of throttling, an API name as identification information of the API that is the target of throttling, and throttling. The deadline for execution of is shown for each combination of user name and API name.

The control unit 35 shown in FIG. 2 includes, for example, a CPU (Central Processing Unit), a ROM (Read Only Memory) that stores programs and various data, and a memory used as a work area of the CPU of the control unit 35. RAM (Random Access Memory) is provided. The CPU of the control unit 35 executes the program stored in the storage unit 34 or the ROM of the control unit 35.

The control unit 35 executes the front-end server program 34a to return a response based on the data corresponding to the API call, the call response unit 35a, the throttling execution unit 35b that executes throttling, and the API call. The API call message enqueue unit 35c for enqueuing the message and the throttling information update unit 35d for updating the throttling information 34b are realized.

FIG. 4 is a block diagram of the back-end server 40 when it is configured by one computer.

As shown in FIG. 4, the back-end server 40 is an operation unit 41 which is an operation device such as a keyboard and a mouse into which various operations are input, and a display which is a display device such as an LCD which displays various information. For example, the unit 42 stores various information with the communication unit 43, which is a communication device that directly communicates with an external device via a network such as a LAN or the Internet, or directly by wire or wirelessly without a network. It includes a storage unit 44 which is a non-volatile storage device such as a semiconductor memory and an HDD, and a control unit 45 which controls the entire back-end server 40.

The storage unit 44 stores the back-end server program 44a, which is a program for the back-end server 40. The back-end server program 44a may be installed on the back-end server 40 at the manufacturing stage of the back-end server 40, or is added to the back-end server 40 from an external storage medium such as a CD, DVD, or USB memory. It may be installed by, or it may be additionally installed on the backend server 40 from the network. The back-end server program 44a constitutes a part of the API call processing program of the present invention.

The storage unit 44 stores the execution condition information 44b indicating the execution condition of throttling.

FIG. 5 is a diagram showing an example of execution condition information 44b.

As shown in FIG. 5, the execution condition information 44b includes the user name of the caller of the API that is the target of throttling, the API name of the API that is the target of throttling, the conditions for executing throttling, and throttling. The execution period of is shown for each combination of user name and API name. The conditions for executing throttling are, for example, "the number of calls exceeds 50 times in 5 minutes", "the number of calls exceeds 100 times in 10 minutes", and the like.

The control unit 45 shown in FIG. 4 includes, for example, a CPU, a ROM for storing programs and various data, and a RAM as a memory used as a work area of the CPU of the control unit 45. The CPU of the control unit 45 executes a program stored in the storage unit 44 or the ROM of the control unit 45.

By executing the back-end server program 44a, the control unit 45 realizes the aggregation result message enqueue unit 45a that enqueues the aggregation result message and the throttling instruction message enqueue unit 45b that enqueues the throttling instruction message.

Next, the operation of the API call processing system 10 will be described.

First, the operation of the front-end server 30 when the API is called from the outside will be described.

FIG. 6 is a flowchart of the operation of the front-end server 30 when the API is called from the outside.

The control unit 35 of the front-end server 30 executes the operation shown in FIG. 6 each time the API is called from the outside.

As shown in FIG. 6, the throttling execution unit 35b of the control unit 35 tells the throttling information 34b whether or not the caller of the target API is currently the target of throttling with respect to this API. Judgment is made based on (S101).

When the caller of the target API determines in S101 that the target API is currently the target of throttling, the throttling execution unit 35b executes throttling, for example, returns a 503 error (for example, returns a 503 error). S102), the operation shown in FIG. 6 is terminated.

When the API call message enqueue unit 35c of the control unit 35 determines in S101 that the caller of the target API is not the target of throttling with respect to this API at the present time, the API regarding the current API call Generate a call message (S103).

FIG. 7 is a diagram showing an example of an API call message generated in the operation shown in FIG.

As shown in FIG. 7, the API call message indicates "timeStamp" indicating the time when the target API is called, "userName" indicating the user name of the caller of the target API, and the API name of the target API. Includes "apiName". In the example shown in FIG. 7, the respective values of "timeStamp", "userName", and "apiName" are "2019/09/10 20:00:10", "User 1", and "API A".

As shown in FIG. 6, the API call message enqueue unit 35c of the control unit 35 enqueues the API call message generated in S103 into the API call queue 51 after the processing of S103 (S104).

Next, the call response unit 35a of the control unit 35 collects data from the database 20 in response to the current API call (S105).

Next, the call response unit 35a returns the response based on the data collected in S105 to the caller of the API this time (S106), and ends the operation shown in FIG.

Next, the operation of the back-end server 40 when counting the number of API calls during a specific time will be described.

FIG. 8 is a flowchart of the operation of the back-end server 40 when the number of API calls during a specific time is totaled.

The control unit 45 of the back-end server 40 executes the operation shown in FIG. 8 at specific time intervals, for example, every minute.

As shown in FIG. 8, the aggregation result message enqueue unit 45a of the control unit 45 attempts to dequeue the API call message from the API call queue 51 (S121).

Next, the aggregation result message enqueue unit 45a determines whether or not the API call message has been dequeued from the API call queue 51 as a result of the attempt in S121 (S122).

When the aggregation result message enqueue unit 45a determines in S122 that the API call message has been dequeued from the API call queue 51, the number of API calls is determined by combining the user name and the API name based on the API call message dequeued in S121. Aggregate for each (S123).

Next, the aggregation result message enqueue unit 45a generates an aggregation result message indicating the aggregation result in S123 for each combination of the user name and the API name (S124).

FIG. 9 is a diagram showing an example of an aggregation result message generated in the operation shown in FIG.

As shown in FIG. 9, the aggregation result message includes "timeStamp" indicating the aggregation start time of the number of calls of the target API, "userName" indicating the user name of the caller of the target API, and the target API. It includes "apiName" indicating the API name of the target API and "count" indicating the number of calls of the target API. In the example shown in FIG. 9, the respective values of "timeStamp", "userName", "apiName", and "count" are "2019/09/10 20:00", "User 1", "API A", and " 80 ". That is, in the example shown in FIG. 9, the API of the API name “API A” is “80” times from the reading source of the user name “User 1” during one minute after “2019/09/10 20:00”. Indicates that it has been called.

As shown in FIG. 8, the aggregation result message enqueue unit 45a enqueues the aggregation result message generated in S124 into the aggregation result queue 52 after the processing of S124 (S125).

When the aggregation result message enqueue unit 45a determines in S122 that the API call message has not been dequeued from the API call queue 51 or executes the process of S125, the operation shown in FIG. 8 ends.

Next, the operation of the back-end server 40 when generating the throttling instruction message will be described.

FIG. 10 is a flowchart of the operation of the back-end server 40 when generating a throttling instruction message.

The control unit 45 of the back-end server 40 executes the operation shown in FIG. 10 at specific time intervals, for example, every 5 minutes. The execution interval of the operation shown in FIG. 10 is longer than the execution interval of the operation shown in FIG.

As shown in FIG. 10, the throttling instruction message enqueue unit 45b of the control unit 45 attempts to dequeue the aggregation result message from the aggregation result queue 52 (S141).

Next, the throttling instruction message enqueue unit 45b determines whether or not the aggregation result message has been dequeued from the aggregation result queue 52 as a result of the attempt in S141 (S142).

When the throttling instruction message enqueue unit 45b determines in S142 that the aggregation result message has been dequeued from the aggregation result queue 52, the number of API calls is determined by the user name and the API name based on the aggregation result message dequeued in S141. Aggregate for each combination (S143).

Next, the throttling instruction message enqueue unit 45b targets only one combination of the user name and the API name, which has not yet been targeted in the operation shown in FIG. 10 this time (S144).

Next, the throttling instruction message enqueue unit 45b determines whether or not the number of times aggregated in S143 satisfies the condition of execution of throttling indicated in the execution condition information 44b with respect to the current target combination (S145).

When the throttling instruction message enqueue unit 45b determines in S145 that the condition for executing throttling is satisfied, it generates a throttling instruction message for the current target combination (S146).

FIG. 11 is a diagram showing an example of a throttling instruction message generated in the operation shown in FIG.

As shown in FIG. 11, the throttling instruction message indicates "userName" indicating the user name of the caller of the target API, "apiName" indicating the API name of the target API, and the deadline for executing throttling. Includes "timeStamp". In the example shown in FIG. 11, the respective values of "userName", "apiName", and "timeStamp" are "User 1", "API A", and "2019/09/10 21:05: 00". That is, in the example shown in FIG. 11, the instruction for throttling the API call of the API name "API A" from the reading source of the user name "User 1" is instructed until "2019/09/10 21:05: 00". Shown. Here, the throttling instruction message enqueue unit 45b sets the deadline for throttling execution by adding the throttling execution period shown in the execution condition information 44b with respect to the current target combination to the current date and time. calculate.

As shown in FIG. 10, the throttling instruction message enqueue unit 45b enqueues the throttling instruction message generated in S146 into the throttling instruction queue 53 after the processing of S146 (S147).

The aggregation result message enqueue unit 45a of the control unit 45 is determined in S145 that the condition for executing throttling is not satisfied, or when the processing of S147 is completed, it is dequeued from the aggregation result queue 52 in S141, and is the current target. Among the aggregation result messages of the combination, whether or not there is an aggregation result message that needs to be re-queued to the aggregation result queue 52 is indicated in the execution condition information 44b for the current target combination. Judgment is made based on (S148). Specifically, in the aggregation result message enqueue unit 45a, the execution interval of the operation shown in FIG. 10 is the target period under the execution condition of throttling, which is shown in the execution condition information 44b with respect to the current target combination (hereinafter, If it is shorter than the "execution condition period"), it is necessary to re-enqueue the aggregation result message including "timeStamp" from the scheduled execution time of the next operation shown in FIG. 10 to before the execution condition period in the aggregation result queue 52. Judge that there is. For example, when the execution interval of the operation shown in FIG. 10 is 5 minutes and the execution condition period is 10 minutes, the aggregation result message enqueue unit 45a is 10 minutes from the scheduled execution time of the next operation shown in FIG. It is determined that the aggregation result message including the previous "timeStamp" needs to be requeued to the aggregation result queue 52.

The aggregation result message enqueue unit 45a determines in S148 that among the aggregation result messages of the current target combination dequeued from the aggregation result queue 52 in S141, there is an aggregation result message that needs to be enqueued again in the aggregation result queue 52. Then, among the aggregation result messages of the current target combination dequeued from the aggregation result queue 52 in S141, the aggregation result message that needs to be requeued to the aggregation result queue 52 is requeued to the aggregation result queue 52 (S149). ).

The throttling instruction message enqueue unit 45b of the control unit 45 has a total result message that needs to be requeued to the total result queue 52 among the total result messages of the current target combination dequeued from the total result queue 52 in S141. It is determined in S148 that it does not exist, or when the process of S149 is completed, it is determined whether or not there is a combination of the user name and the API name that has not yet been targeted in the operation shown in FIG. 10 this time (S150).

When the throttling instruction message enqueue unit 45b determines in S150 that there is a combination of a user name and an API name that has not yet been targeted in the operation shown in FIG. 10 this time, it executes the process of S144.

The throttling instruction message enqueue unit 45b determines in S142 that the aggregation result message has not been dequeued from the aggregation result queue 52, or a combination of a user name and an API name that has not yet been targeted in the operation shown in FIG. If it is determined in S150 that it does not exist, the operation shown in FIG. 10 ends.

Next, the operation of the front-end server 30 when updating the throttling information 34b will be described.

FIG. 12 is a flowchart of the operation of the front-end server 30 when the throttling information 34b is updated.

The control unit 35 of the front-end server 30 executes the operation shown in FIG. 12 at specific time intervals, for example, every 5 minutes.

As shown in FIG. 12, the throttling information updating unit 35d of the control unit 35 attempts to dequeue the throttling instruction message from the throttling instruction queue 53 (S161).

Next, the throttling information update unit 35d determines whether or not the throttling instruction message has been dequeued from the throttling instruction queue 53 as a result of the attempt in S161 (S162).

When the throttling information updating unit 35d determines in S162 that the throttling instruction message has been dequeued from the throttling instruction queue 53, the throttling information updating unit 35d updates the throttling information 34b based on the throttling instruction message dequeued in S161 (S163).

When the throttling information update unit 35d determines in S162 that the throttling instruction message has not been dequeued from the throttling instruction queue 53, or ends the process of S163, the operation shown in FIG. 12 ends.

As described above, the API call processing system 10 enqueues the API call message into the API call queue 51 (S104) when the API is called, and indirectly to the API call message held in the API call queue 51. Since the throttling information 34b is updated based on (S163), it is not necessary to provide a table or database for managing the number of times and history of API usage in the past, and the API call processing system 10 itself is used when restricting API usage. It is possible to reduce the possibility of interfering with the operation of.

In the API call processing system 10, the back-end server 40 generates a throttling instruction message indirectly based on the API call message held in the API call queue 51 (S146), and the front-end server is based on the throttling instruction message. Since 30 updates the throttling information 34b (S163), the use of the API is compared with the case where the front-end server 30 updates the throttling information 34b directly based on the API call message held in the API call queue 51. It is possible to reduce the load on the front-end server 30 that limits the number of API calls, and as a result, it is possible to reduce the possibility that the operation of the API call processing system 10 itself will be hindered when the use of the API is restricted.

In the API call processing system 10, the back-end server 40 generates an aggregation result message based on the API call message held in the API call queue 51 (S124), and the aggregation result is at an interval longer than the interval for generating the aggregation result message. Since the back-end server 40 generates a throttling instruction message based on the message (S146), there is a case where the back-end server 40 generates a throttling instruction message directly based on the API call message held in the API call queue 51. In comparison, the possibility that the back-end server 40 is temporarily heavily loaded can be reduced, and as a result, the operation of the API call processing system 10 itself may be hindered when the use of the API is restricted. Can be reduced.

In the present embodiment, the back-end server 40 generates an aggregation result message based on the API call message held in the API call queue 51 (S124), and based on the aggregation result message held in the aggregation result queue 52. Generate a throttling instruction message (S146). That is, in the present embodiment, the back-end server 40 generates a throttling instruction message indirectly based on the API call message held in the API call queue 51. However, the backend server 40 may generate a throttling instruction message based directly on the API call message held in the API call queue 51.

In the API call processing system 10, in the present embodiment, the back-end server 40 generates an aggregation result message based on the API call message held in the API call queue 51 (S124), and the API call processing system 10 is held in the aggregation result queue 52. The back-end server 40 generates a throttling instruction message based on the aggregation result message (S146), and the front-end server 30 updates the throttling information 34b based on the throttling instruction message held in the throttling instruction queue 53. (S163). That is, in the present embodiment, the API call processing system 10 updates the throttling information 34b indirectly based on the API call message held in the API call queue 51. However, the API call processing system 10 may update the throttling information 34b directly based on the API call message held in the API call queue 51. That is, in the API call processing system 10, the front-end server 30 may update the throttling information 34b based on the API call message held in the API call queue 51 and the execution condition information.

In the present embodiment, the identification information of the caller of the API is a user name, but identification information other than the user name such as an IP (Internet Protocol) address may be used.

10 API call processing system 30 Front-end server 34a Front-end server program (part of API call processing program)
34b Throttling information 35a Call response unit 35b Throttling execution unit 35c API call message enqueue unit 35d Throttling information update unit 40 Back-end server 44a Back-end server program (part of API call processing program)
45a Aggregation result message enqueue section 45b Throttling instruction message enqueue section 51 API call queue 52 Aggregation result queue 53 Throttling instruction queue

Claims (4)

A call response unit that returns a response based on the data corresponding to the API call, and
A throttling execution unit that executes the throttling based on the throttling information indicating the contents of the throttling that is a restriction on the use of the API, and
An API call queue for holding an API call message, which is a message for each API call, and
An API call message enqueue unit that enqueues the API call message to the API call queue when the API is called, and
An API call processing system including a throttling information update unit that updates the throttling information directly or indirectly based on the API call message held in the API call queue. A throttling instruction queue for holding the throttling instruction message, which is a message instructing throttling, and
It is provided with a throttling instruction message enqueue unit that enqueues the throttling instruction message into the throttling instruction queue.
The call response unit, the throttling execution unit, the API call message enqueue unit, and the throttling information update unit are realized by a front-end server.
The throttling instruction message enqueue unit is realized by the back-end server.
The throttling instruction message enqueue unit generates the throttling instruction message directly or indirectly based on the API call message held in the API call queue, and the generated throttling instruction message is used as the throttling instruction. Enqueue to the queue,
The API call processing system according to claim 1, wherein the throttling information updating unit updates the throttling information based on the throttling instruction message held in the throttling instruction queue. An aggregation result queue for holding an aggregation result message, which is a message indicating the aggregation result of the number of API calls, and
It is provided with an aggregation result message enqueue unit that enqueues the aggregation result message into the aggregation result queue.
The aggregation result message enqueue unit is realized by the back-end server.
The aggregation result message enqueue unit generates the aggregation result message based on the API call message held in the API call queue, and enqueues the generated aggregation result message into the aggregation result queue.
The throttling instruction message enqueue unit generates the throttling instruction message based on the aggregation result message held in the aggregation result queue, enqueues the generated throttling instruction message to the throttling instruction queue, and then enqueues the generated throttling instruction message into the throttling instruction queue.
The API call process according to claim 2, wherein the interval at which the throttling instruction message enqueue unit generates the throttling instruction message is longer than the interval at which the aggregation result message enqueue unit generates the aggregation result message. system. A call response unit that returns a response based on the data corresponding to the API call, and
A throttling execution unit that executes the throttling based on the throttling information indicating the throttling content that is a restriction on the use of the API, and a throttling execution unit.
In the API call queue for holding the API call message, which is a message for each API call, the API call message enqueue unit that enqueues the API call message when the API is called, and an API call message enqueue unit.
An API call processing program, characterized in that a computer realizes a throttling information update unit that updates the throttling information directly or indirectly based on the API call message held in the API call queue.

Images