API system

Abstract

To provide a user-friendly API system by focusing on a technology for linking a plurality of APIs.SOLUTION: An API system 1 of the present invention comprises a plurality of APIs 6 that executes a function corresponding to a processing request RQ and provides it as a processing response RS. The plurality of APIs 6 has a superclass S that defines common rules for exchanging the processing request RQ and the processing response RS between them. A group of the APIs 6 associated with the processing request RQ from an application 5 exchanges the processing request RQ and the processing response RS in accordance with the superclass S, and generates the processing response RS for the application 5.SELECTED DRAWING: Figure 5

Description

[Technical Field]

[0001] The present invention relates to an API system. [Background technology]

[0002] In recent years, with the development of IoT technology and growing health awareness, information processing systems have become known that are configured to generate tasks and advice messages for users based on physical information, etc., estimated by analyzing the user's current and past behavioral patterns (see, for example, Patent Document 1). Also disclosed is an information processing system that identifies nutrients that the user is lacking based on the user's responses and suggests supplements containing the lacking nutrients (see, for example, Patent Document 2). [Prior art documents] [Patent documents]

[0003] [Patent Document 1] Patent No. 6244476 [Patent Document 2] Patent No. 6586499 Summary of the Invention [Problem to be solved by the invention]

[0004] Incidentally, medical information related to health management is generally not only enormous in volume but also updated frequently. However, in the conventional information processing system, each time medical information is updated, it is understood that a part of the program implemented on the management server must be changed or modified without causing any malfunctions in the entire program, which is a concern as it imposes a heavy burden on developers. It is also understood that this will result in the problem of a long time being required to re-present the changed or modified information processing system to users.

[0005] In recent years, application programming interfaces (hereafter referred to as "APIs") that allow external applications (hereafter referred to as "apps") to access functions and information have become increasingly common. For example, using an API that has already been developed and made public can make app development more efficient than manually coding a program that achieves the same functionality as the API. It is also possible to link (mash up) multiple APIs.

[0006] The present invention was made in consideration of the problems with the prior art described above, and the applicant focused on technology for linking multiple APIs and completed the present invention. [Means for solving the problem]

[0007] The present invention is an API system that has multiple APIs that execute functions corresponding to processing requests and provide them as processing responses, wherein the multiple APIs have a superclass that defines common rules for exchanging processing requests and processing responses between them, and a group of APIs associated with a processing request from an application exchanges processing requests and processing responses in accordance with the superclass and generates a processing response to the application.

[0008] In the API system of the present invention, the body portion of a processing response may be configured to recursively extract processing responses of all preceding APIs when generating the processing response.

[0009] In the API system of the present invention, the data type of the processing request and the processing response of each API may be a character string. [Effects of the Invention]

[0010] According to the present invention, multiple APIs have a superclass that defines common rules for exchanging processing requests and processing responses between them, and the APIs associated with processing requests from an application exchange processing requests and processing responses according to the superclass and generate processing responses to the application, so functions and information can be distributed and processed for each API, making it easy to combine APIs to support a wide variety of services, thereby enabling the construction of a flexible API system with a high degree of freedom.

[0011] In particular, even when updating with the latest information or adding services that meet new needs, it is sufficient to make changes, modifications, or additions to each relevant API without affecting the entire API system, which significantly reduces the burden on developers and shortens the time it takes to re-present the API system to users after making changes, modifications, or additions. [Brief explanation of the drawings]

[0012] [Figure 1] 1 is an explanatory diagram illustrating the overall configuration of an API system according to an embodiment. [Figure 2] FIG. 2 is a block diagram showing the functional configuration of an API device. [Figure 3] FIG. 2 is a block diagram showing the hardware configuration of the API device. [Figure 4] FIG. 2 is a block diagram showing the hardware configuration of a user terminal. [Figure 5] FIG. 2 is a sequence diagram showing how the API system is used in the first example. [Figure 6] FIG. 4 is a schematic diagram showing the data structure of a processing request in the first example. [Figure 7] FIG. 10 is a schematic diagram showing the data structure of a processing response in the first example. [Figure 8] FIG. 10 is a schematic diagram showing the data structure of a processing request in the second example. [Figure 9] FIG. 10 is a sequence diagram showing how the API system is used in the third example. [Figure 10] FIG. 11 is a schematic diagram showing the data structure of a processing request in the third example. [Figure 11] FIG. 11 is a schematic diagram showing the data structure of a processing response in the third example. [Figure 12] FIG. 11 is a schematic diagram showing the data structure of a processing request after restart in the third example. [Figure 13] FIG. 10 is a sequence diagram showing how the API system is used in the fourth example. [Figure 14] FIG. 10 is an explanatory diagram showing how the API system is used in the fifth example. [Figure 15] FIG. 13 is an explanatory diagram showing how the API system is used in the sixth example. DETAILED DESCRIPTION OF THE INVENTION

[0013] Next, embodiments embodying the present invention will be described with reference to the drawings. While the drawings show preferred embodiments, the present invention can be embodied in many different forms and is not limited to the embodiments described herein.

[0014] First, an overview of an API system 1 according to an embodiment will be described with reference to Fig. 1 etc. Fig. 1 is an explanatory diagram showing the overall configuration of API system 1 according to an embodiment. API system 1 (hereinafter simply referred to as "system 1") includes an API device 3 operated by a service provider. API device 3 is made up of one or more computers and functions as, for example, a web server on communication network 2.

[0015] The communication network 2 is configured by, for example, the Internet, a mobile communication network, and base stations, but there are no restrictions on the type of communication protocol, or on the type or scale of the network. Furthermore, the API device 3 is not limited to an on-premise server (installed and operated within the facility of the service provider), but may be a cloud server virtually provided on the communication network 2.

[0016] The API device 3 is configured to be communicatively connected to a group of user terminals 4 of users who use the API system 1 via a communication network 2. Each user terminal 4 is, for example, a smartphone, tablet, or personal computer, and is capable of exchanging various types of information with the API device 3.

[0017] Each user terminal 4 in the embodiment is used by a user to utilize an application 5. The application 5 is provided with functions and information of each API 6 implemented in the API device 3, and may be a client-side application 5 distributed to each user terminal 4 or a server-side application 5 executed on a server.

[0018] In the case of a client-side application 5, the client-side application 5 is executed on the user terminal 4, and in the case of a server-side application 5, a browser or the like is executed on the user terminal 4 to access the server, and the server-side application 5 is executed on the server. The server-side application 5 may be implemented on a server separate from the API device 3, or may be implemented on the API device 3. Figure 1 shows an example in which a client-side application 5 is used.

[0019] In the embodiment, the user terminal 4 executes the application 5, accesses the API device 3 by, for example, HTTP (Hypertext Transfer Protocol), and establishes a communication session with the API device 3. Next, the user terminal 4 requests the API device 3 to provide information, receives a response from the API device 3 that has executed processing in response to the request, and displays the provided information via the application 5.

[0020] When requesting information provision from the API device 3, the user terminal 4 transmits a processing request RQ to a predetermined API 6 via the application 5. When receiving a response from the API device 3, the user terminal 4 receives a processing response RS from the predetermined API 6 via the application 5.

[0021] An application 5 is assigned in advance an API key 7 associated with the ID of the application 5. A processing request RQ sent from the application 5 to the API device 3 (predetermined API 6) includes the API key 7. The API key 7 authenticates the application 5, and identifies the application 5 of the user terminal 4 that uses the API system 1.

[0022] The app 5 of the embodiment is, for example, health management application software that provides a user with health-related services and supports the user's health management. Note that the app 5 used in the API system 1 of the present invention is not limited to health management application software, and various application software for providing services can be adopted. For example, the app 5 may be accounting audit application software that supports accounting audit-related work, tax application software that supports tax-related work, or social insurance and labor application software that supports social insurance and labor-related work.

[0023] The API device 3 is equipped with multiple APIs 6 that execute functions corresponding to processing requests RQ and provide them as processing responses RS (see FIG. 2). Each API 6 is used by the application 5 to use functions and information. In the embodiment, a WebAPI is used as an example of an API 6. Unless otherwise specified in the following description, API 6 refers to a "WebAPI (REST API)." In the following description, API 6 may be referred to with an alphabetical character to distinguish the type. Furthermore, processing requests RQ and processing responses RS may be referred to with a number.

[0024] Here, a REST API is an API that follows the design principles of REST (Representational State Transfer). In a REST API, a processing request RQ using HTTP methods such as GET and POST and a URL (Uniform Resource Locator) is sent from a user terminal 4 to an API device 3, and a processing response RS is received from the API device 3 in a format such as JSON (Javascript Object Notation) or XML (Extensible Markup Language).

[0025] The features of API6 (WebAPI (REST API)) in this embodiment include the fact that it identifies a unique resource by including {API name} in the request URL, and that it is essentially stateless (all necessary data is sent when a processing request is made, and the results are obtained immediately with the processing response). Another feature is that the success or failure of the processing request is also output as a status code in the processing response.

[0026] In the embodiment, the APIs 6 are configured to provide functions and information about health-related services, for example. The APIs 6 are roughly divided into three groups: those related to the user's body, those that determine the user's health condition from the user's body, and those that provide advice information useful for health management based on the determination.

[0027] Examples of the user's physical information include height API 6a, weight API 6b, age API 6c, gender API 6d, serum creatinine level API 6e, urinary protein level API 6f, fasting blood glucose API 6g, systolic blood pressure API 6h, LDL cholesterol level API 6i, HDL cholesterol level API 6j, smoking status API 6k, and medical history API 6l.

[0028] Items used to assess a user's health status include BMI (body mass index) API6m, obesity assessment API6s, eGFR (estimated glomerular filtration rate) API6n, GFR classification API6o, chronic kidney disease severity classification API6p, Hisayama Town score API6q, and arteriosclerotic disease development risk API6r.

[0029] Examples of APIs that provide advice information include a weight advice API 6t, a kidney advice API 6u, and a risk assessment advice API 6v.

[0030] The above group of APIs 6 is merely an example and is not limited to the above. Various APIs can be used as long as they provide functions and information related to health-related services. Furthermore, the API 6 of the present invention is not limited to those providing functions and information related to health-related services, and can be used for various services. For example, it may be for accounting audit-related services, tax-related services, or social insurance and labor-related services.

[0031] Each API 6 implements a superclass S that defines common rules (common characteristics and behaviors) for exchanging processing requests RQ and processing responses RS between them. The endpoints of each API 6 inherit and use the common superclass S. Therefore, processing requests RQ and processing responses RS are transmitted and received between the application 5 and each API 6, and between the APIs 6, based on the common transmission and reception rules. Therefore, each API 6 in the embodiment can execute processing as an API 6 for input, and can also execute processing as an API 6 for output.

[0032] As will be described in detail later, the APIs 6 associated with the processing request RQ from the application 5 are configured to exchange the processing request RQ and the processing response RS in a bidirectional list format according to the superclass S, and to generate the processing response RS to the application 5. Here, the bidirectional list format means that data can be exchanged in both directions, from one side to the other and from the other side to the other.

[0033] 3 is a block diagram showing the hardware configuration of the API device 3 and the user terminal 4. The API device 3 includes a CPU 11, a ROM 12, a RAM 13, a HDD 14, a communication I / F 15, and a connection I / F 16. The units 11 to 16 are connected to one another via a system bus 19.

[0034] The CPU 11 is a central processing unit that executes arithmetic processing and control processing. The CPU 11 loads various programs stored in the ROM 12, HDD 14, etc. into the RAM 13, executes various processes, and controls the API device 3 in an integrated manner. The ROM 12 is a non-volatile memory that stores fixed programs (such as BIOS). The RAM 13 is a volatile memory that the CPU 11 uses as a work area for various processes. The HDD 14 is an auxiliary storage device that stores various programs and data. The various programs include an operating system and multiple APIs 6, etc. The communication I / F 15 has a function of connecting the API device 3 to the communication network 2 for communication. The connection I / F 16 is an interface such as a USB standard that connects an external device to the API device 3.

[0035] Fig. 4 is a block diagram showing the hardware configuration of the user terminal 4. As shown in Fig. 4, the user terminal 4 includes a CPU 21, a ROM 22, a RAM 23, a flash memory 24, a communication I / F 25, a connection I / F 26, a touch panel 27, and an LCD 28. The components 21 to 28 are connected to one another via a system bus 29.

[0036] The CPU 21 is a central processing unit that executes arithmetic processing and control processing. The CPU 21 reads various programs stored in the ROM 22, flash memory 24, etc. into the RAM 23, and executes various processes to comprehensively control the user terminal 4. The ROM 22 is a non-volatile memory that stores fixed programs (such as BIOS). The RAM 23 is a volatile memory that the CPU 21 uses as a work area for various processes. The flash memory 24 is an auxiliary storage device that stores various programs, data, etc. The various programs include an operating system, apps 5, etc.

[0037] The communication I / F 25 has a function of connecting the user terminal 4 to the communication network 2. The connection I / F 26 is an interface such as a USB standard interface that connects an external device to the user terminal 4. The touch panel 27 is a sensor that detects the position of a touch on the LCD 28 screen by the user and transmits information about the touch position to the CPU 21. The LCD 28 is an example of a notification means, and displays information output from the CPU 21 on the screen. Note that, as a notification means for notifying the information output from the CPU 21, in addition to the LCD 28, which is a display notification means, audio output means or the like may also be used. Furthermore, the information output from the CPU 21 of the user terminal 4 can be transmitted to various home appliances and used as setting information for the home appliances. In this case, the various home appliances function as the notification means.

[0038] Next, an example of the operation of the system 1 according to the embodiment will be described with reference to Figs. 5 to 15. The first example shown in Figs. 5 to 7 is a case where a user checks his / her own BMI using a user terminal 4, and a predetermined API key 7 is assigned in advance to the app 5 of the user terminal 4. The first example illustrates a case where a response of function and information of a health-related service is obtained in JSON format with a single request.

[0039] In the first example, specific data related to API6, such as the user's height and weight, that is related to the user's body (data passed to API6a to API6l) is assumed to have already been loaded into app 5 on user terminal 4 from the information provision and record disclosure system (My Number Portal) based on the Act on the Use of Numbers to Identify Specific Individuals in Administrative Procedures (Act No. 27 of 2013), or from health checkup result data received from the health checkup institution, or has been directly entered into app 5 by the user.

[0040] 5, the user first operates the application 5 of the user terminal 4 to establish a communication session with the API device 3, and then generates a processing request RQ1 for obtaining the user's own BMI using the application 5 (step S01).Then, the processing request RQ1 is sent to a BMI API 6m among the APIs 6 of the API device 3 (step S02).

[0041] Figure 6 shows a schematic diagram of an example of the data structure of a processing request RQ1. The entire processing request RQ1 is written as a character string, and the structure is determined line by line, separated by a line feed code. In other words, the data type of processing request RQ1 is a character string.

[0042] The processing request RQ1 includes a line portion 31, a header portion 32, and a body portion 33. The processing request RQ1 begins with the line portion 31. The line portion 31 begins with the requested HTTP method and describes a URL that identifies the requested resource. In the case of the processing request RQ1 in the first example, BMIAPI6m is entered in the {API name} field in the URL.

[0043] Next to the line section 31 is the header section 32. The header section 32 is used to pass the request itself and additional information about the application 5 that made the request to the API device 3 (BMIAPI 6m) that is the request destination. In the first example, the header section 32 of the processing request RQ1 describes, as a character string, the type of data to be sent from the application 5 to the BMIAPI 6m and the API key 7 associated with the ID of the application 5 that made the request. The API device 3 (BMIAPI 6m in this case) checks the API key 7 included in the header section 32 and determines whether authentication is successful or unsuccessful.

[0044] The header section 32 is followed by a body section 33. The body section 33 describes the data itself to be passed from the application 5 to the API device 3 (BMIAPI 6m) depending on the type of HTTP method of the request. Note that depending on the HTTP method, the body section 33 may not exist. In the body section 33 of the processing request RQ1 in the first example, the height and weight values ​​stored in the application 5 are described as character strings.

[0045] 5, when the BMIAPI 6m receives the processing request RQ1, it checks the API key 7 included in the header 32 of the processing request RQ1 and determines whether the authentication was successful or unsuccessful (step S03). If the authentication was unsuccessful (S03: NO), the BMIAPI 6m sends an error processing response RS4 to the application 5 of the user terminal 4 (step S12).

[0046] If the authentication is successful (S03: YES), the BMI API 6m first sends the height data included in the body part 33 to the height API 6a as a processing request RQ2 (step S04) and sends the weight data to the weight API 6b as a processing request RQ3 (step S05) in accordance with the common rules of the superclass S. The height API 6a returns the received height data to the BMI API 6m as a processing response RS1 (step S06), and similarly, the weight API 6b returns the received weight data to the BMI API 6m as a processing response RS2 (step S07). Note that the first example employs a setting in which the height API 6a and the weight API 6b do not store corresponding height or weight data.

[0047] Then, the BMIAPI 6m executes a process to calculate BMI from the height and weight data based on the contents of the processing request RQ1 and the processing responses RS1 and RS2 (step S08). Next, the BMIAPI 6m generates a processing response RS3 based on the calculation process of step S08 (step S09) and transmits this to the user terminal 4 (step S10). The user terminal 4 that receives the processing response RS3 of the BMIAPI 6m displays the BMI value, which is the calculation result, via the application 5 (step S11).

[0048] FIG. 7 is a schematic diagram showing an example of the data structure of the processing response RS3 passed from the BMIAPI 6m to the user terminal 4. Like the processing request RQ1, the processing response RS3 is written entirely as a character string, with the structure determined line by line, separated by a linefeed code. In other words, the data type of the processing response RS3 is also a character string. Needless to say, the data types of the processing requests RQ2 and RQ3 and the processing responses RS1, RS2, and RS4 are all character strings. Setting the data type to a character string makes it possible to handle Base64-encoded binary data and to include one or more files in PDF, CSV, JSON, image data, and other well-known formats.

[0049] The processing response RS3 includes a line section 41, a header section 42, and a body section 43. The line section 41 of the processing response RS3 describes a status code indicating whether the request was completed successfully. The header section 42 of the processing response RS3 is used to pass additional information about the response itself and the data in the body section 43 to the application 5 that sent the request. The header section 42 of the processing response RS3 in the first example describes, in a character string, the type of data to be sent from the BMIAPI 6m to the application 5. The body section 43 of the processing response RS1 describes the data itself to be passed from the API device 3 (BMIAPI 6m) to the application 5.

[0050] In the body part 43 of the processing response RS3, not only the calculation result data (BMI data in this case) described in the processing response RS3 but also the processing responses RS1 and RS2 of all the preceding APIs 6 (6a and 6b) that were extracted recursively in generating the processing response RS3. That is, in the first example, the processing content 44 of the BMI API 6m, the processing content 45 of the height API 6a, and the processing content 46 of the weight API 6b are extracted recursively in the body part 43 of the processing response RS3.

[0051] The processing content 44 of the BMI API 6m describes the API name (BMI), status code (1 (meaning normal)), result (26.8), etc. The processing content 45 of the height API 6a describes the API name (height), status code (1), result (171.2), etc. The processing content 46 of the weight API 6b describes the API name (weight), status code (1), result (78.5), etc.

[0052] Next, a second example in which a query format is used for the processing request RQ4 will be described with reference to Fig. 8. The second example is a case in which BMI is confirmed on the user terminal 4, and the prerequisites, such as the assignment of the API key 7, are the same as those in the first example. Note that, although details are omitted, in the second example, the generation of the processing request RQ4 in query format is executed by operating the application 5 on the user terminal 4.

[0053] In the processing request RQ4 of the second example, the type of data sent from the application 5 to the BMI API 6m has changed from JSON format to query format, and therefore the corresponding section in the header section 32 has been changed from "json" to "x-www-form-urlencoded." In the body section 33 of the processing request RQ4 of the second example, the query parameter is written as a character string with the content "revision=1&height=171.2&weight=78.5." The processing request RQ4 of the second example shown in FIG. 8 also functions in the same way as the first example. Note that in the second example, the processing response RS to the processing request RQ4 is, in principle, issued in JSON format.

[0054] Next, a third example of a case where specific data related to the API 6 relating to the body (data passed to API 6a to API 6l) is temporarily stored in the system 1 will be described with reference to Figures 9 to 12. In the third example, the prerequisites for granting the API key 7 are the same as in the first example. It is assumed that various types of body-related data have already been loaded into the app 5 of the user terminal 4 from My Number Portal, health check result data, etc., or have been directly entered into the app 5 by the user.

[0055] 9, the user first operates the application 5 of the user terminal 4 to establish a communication session with the API device 3, and then generates a processing request RQ6 for temporarily storing various body-related data using the application 5 (step S21).Then, the user transmits the processing request RQ6 to the API device 3 (step S22).

[0056] FIG. 10(a) shows a schematic diagram of the data structure of processing request RQ6. The data type of processing request RQ6 is also a character string. In the line section 31 of processing request RQ6, "https: / / api.wellcle.co.jp / in / " is written as the URL. The description in header section 32 is the same as in the first example (see FIG. 6). In body section 33, various types of health-related data are written. Note that if the health information to be obtained is predetermined, {API name} may be written in the URL of line section 31 of processing request RQ6 (see FIG. 10(b)).

[0057] 9, upon receiving the processing request RQ6, the API device 3 uses the API key 7 to determine whether authentication is successful or unsuccessful (step S23). If authentication is unsuccessful (S23: NO), the API device 3 sends an error processing response RS5 to the application 5 of the user terminal 4 (step S30). If authentication is successful (S23: YES), the API device 3 stores various body-related data (step S24) and generates a processing response RS6 corresponding to the processing request RQ6 (step S25).

[0058] FIG. 11(a) shows a schematic diagram of the data structure of the processing response RS6 passed from the API device 3 to the user terminal 4. The data type of the processing response RS6 is also a character string. The body section 43 of the processing response RS6 contains {session ID}, which indicates that various body-related data has been stored. Note that if {API name} is described in the URL of the line section 31 of the processing request RQ6, a URL including {API name} and {session ID} will be described in the body section 43 of the processing response RS6 (see FIG. 11(b)).

[0059] 9, after executing step S25, the API device 3 transmits a processing response RS6 based on the processing of step S25 to the user terminal 4 (step S26). The user terminal 4 that receives the processing response RS6 of the API device 3 stores the {session ID} described in the processing response RS6 (step S27).

[0060] Thereafter, when the user wants to check the BMI on the user terminal 4, the application 5 of the user terminal 4 generates a processing request RQ7 for requesting the BMI (step S28), and then transmits the processing request RQ7 to the API device 3 (step S29).

[0061] 12(a) to 12(c) show schematic diagrams of the data structure of processing request RQ7. The data type of processing request RQ7 is also a character string. In line section 31 of processing request RQ7, "https: / / api.wellcle.co.jp / out / {API name}" is written as the URL. In the third example of processing request RQ7, BMIAPI6m is entered in place of {API name} in the URL of line section 31.

[0062] The processing request RQ7 includes a {session ID}. In this case, the {session ID} may be written in the header section 32, may be written as a cookie in the header section 32, or may be written in the URL of the line section 31 (see FIGS. 12(a) to 12(c)). The description in the body section 33 of the processing request RQ7 may be the same as in the first example (see FIG. 6) or the second example (see FIG. 8).

[0063] The flow from step S29 onwards is similar to that from step S04 onwards in the first example, and therefore a detailed description will be omitted. By carrying out the above flow, health information can be repeatedly acquired using various body-related data temporarily stored in the system 1. It is desirable to set an expiration date for various body-related data, and to delete data that has passed the expiration date.

[0064] Next, a fourth example of a case where an obesity determination is confirmed using the user terminal 4 will be described with reference to Fig. 13. In the fourth example, the prerequisites such as the assignment of the API key 7 are the same as those in the first example.

[0065] 13, the user first operates the application 5 of the user terminal 4 to establish a communication session with the API device 3, and then generates a processing request RQ11 requesting advice on obesity assessment using the application 5 (step S31).Then, the processing request RQ11 is sent to the weight advice API 6t of the API device 3 (step S32).

[0066] Next, the weight advice API 6t that has received the processing request RQ11 checks the API key 7 included in the header section 32 of the processing request RQ11 and determines whether authentication was successful or unsuccessful (step S33). If authentication was unsuccessful (S33: NO), the weight advice API 6t sends an error processing response RS16 to the application 5 of the user terminal 4 (step S50).

[0067] If the authentication is successful (S33: YES), the weight advice API 6t sends the data of the body part 33 to the obesity determination API 6s as a processing request RQ12 in accordance with the common rules of the superclass S (step S34), and the obesity determination API 6s sends the data of the body part 33 to the BMI API 6m as a processing request RQ13 (step S35). Next, upon receiving the processing request RQ13 from the obesity determination API 6s, the BMI API 6m sends the height data included in the body part 33 to the height API 6a as a processing request RQ14 (step S36) and sends the weight data to the weight API 6b as a processing request RQ15 (step S37).

[0068] The height API 6a returns the received height data to the BMI API 6m as a processing response RS11 (step S38), and the weight API 6b returns the received weight data to the BMI API 6m as a processing response RS12 (step S39).

[0069] Then, the BMI API 6m executes a process to calculate BMI from the height and weight data based on the contents of the processing request RQ13 and the processing responses RS11 and RS12 (step S40). Next, the BMI API 6m generates a processing response RS13 based on the calculation process of step S40 (step S41) and sends this to the obesity determination API 6s (step S42). The obesity determination API 6s determines whether or not the subject is obese based on the BMI value result based on the contents of the processing request RQ12 and the processing response RS13 (step S43).

[0070] Next, the obesity determination API 6s generates a processing response RS14 based on the determination processing of step S43 (step S44) and sends this to the weight advice API 6t (step S45). Upon receiving the processing response RS14 from the obesity determination API 6s, the weight advice API 6t creates and processes advice in line with the results of the obesity determination based on the processing request RQ11 and the contents of the processing response RS14 (step S46).

[0071] Next, the weight advice API 6t generates a processing response RS15 based on the processing of step S46 (step S47) and transmits this to the user terminal 4 (step S48). Upon receiving the processing response RS15 of the weight advice API 6t, the user terminal 4 displays advice based on the result of the obesity determination via the application 5 (step S49).

[0072] As can be seen from the relationship between the first and fourth examples, in the embodiment, the BMI API 6m can be an API endpoint for the application 5, and the weight advice API 6t can be an API endpoint for the application 5. Although details are omitted, it is also possible to set the obesity determination API 6s as an API endpoint for the application 5. These points are similar to those for the other APIs 6.

[0073] The functions and information of the health-related services provided by the system 1 of the present invention are not limited to those described above. For example, as shown in the fifth example in FIGS. 2 and 14, data on age (API 6c), gender (API 6d), and serum creatinine (API 6e) are passed to an eGFR (estimated glomerular filtration rate) API 6n for calculation and processing. The calculation results of the eGFR API 6n are then passed to a GFR classification API 6o for calculation and processing. The calculation results of the GFR classification API 6o are then passed to a chronic kidney disease severity classification API 6p for calculation and processing. The chronic kidney disease severity classification API 6p further adds data on urinary protein (API 6f) and performs calculation and processing. Finally, the calculation results of the chronic kidney disease severity classification API 6p are passed to a kidney advice API 6u for processing, allowing the system 1 to provide advice on kidney health to the user.

[0074] 2 and 15, the data for age API6c, gender API6d, fasting blood glucose API6g, systolic blood pressure API6h, LDL cholesterol level API6i, HDL cholesterol level API6j, and smoking status API6k are passed to the Hisayama Town Score API6q for calculation. The calculation result of the Hisayama Town Score API6q is then passed to the arteriosclerotic disease risk API6r for calculation. The arteriosclerotic disease risk API6r then adds the medical history data API6l for calculation. Finally, the calculation result of the arteriosclerotic disease risk API6r is passed to the risk assessment advice API6v for processing. This allows the system 1 to provide advice to the user in accordance with the arteriosclerotic disease prevention guidelines.

[0075] With the above configuration, functions and information can be distributed and processed for each API 6, making it easy to combine API 6 to support a wide variety of services. This allows for the construction of a highly flexible system 1. In particular, even when updating with the latest information or adding services that meet new needs, it is sufficient to make changes, modifications, or additions to each relevant API 6 without affecting the entire system 1. This significantly reduces the burden on developers and shortens the time it takes to re-present system 1 to users after making changes, modifications, or additions.

[0076] Furthermore, in the system 1, the body part 43 of the processing response RS recursively extracts the processing responses RS of all preceding APIs 6 when generating the processing response RS, thereby improving the ease of handling data processed by the APIs 6.

[0077] Furthermore, in system 1, since the data type of the processing request RQ and processing response RS of each API 6 is a string, it is possible to handle Base64 encoded binary data, and one or more files in PDF, CSV, JSON, image data, and other well-known formats can be included in the processing request RQ or processing response RS.

[0078] The configuration of each part in the present invention is not limited to the illustrated embodiment, and various modifications are possible within the scope of the present invention. [Explanation of symbols]

[0079] RQ Processing request RS Processing Response S Superclass 1. API System 2. Communication Network 3 API equipment 4. User terminal 5. Apps 6 API 7. API Key 31 Line section (of processing request) 32 Header section (of processing request) 33 Body (of the request) 41 (Processing response) line section 42 Header section (of processing response) 43 Body (of the processed response)

Claims

1. An API system having a plurality of APIs that executes functions corresponding to processing requests and provides them as processing responses, the plurality of APIs have a superclass in which common rules for exchanging processing requests and processing responses between them are defined; The APIs associated with a processing request from an application exchange the processing request and the processing response according to the superclass, and generate the processing response to the application. API system.

2. The body of the processing response includes all the processing responses of the APIs that preceded the processing response being generated.

2. The API system according to claim 1.

3. The data type of the processing request and the processing response of each API is a string.

3. The API system according to claim 1 or 2.

Images