Information processing device, information processing method, and program

Abstract

This can reduce the burden on developers who create source code based on Web API specifications. [Solution] The system includes specification information indicating a Web API (Application Programming Interface) specification and a first code generated based on the Web API specification. The system identifies the naming convention for the information contained in the first code and generates a source file to which the second code processed in the first code is added, based on the naming convention.

Description

[[Technical Field]]

[0001] Embodiments of the present invention relate to an information processing apparatus, an information processing method, and a program. [[Background Art]]

[0002] A third-party open source software (OSS) called openapi-generator that automatically generates skeleton code from a Web API (Application Programming Interface) specification document (api-specs.yaml) described in accordance with the openapi-specification has been conventionally known. [[Prior Art Literature]] [[Patent Literature]]

[0003] [[Patent Literature 1]] Japanese Patent No. 6795531 [[Summary of the Invention]] [[Problem to be Solved by the Invention]]

[0004] However, with conventional techniques, it has been difficult to reduce the burden on developers who create source code based on Web API specification information. [[Means for Solving the Problem]]

[0005] The information processing apparatus of an embodiment includes a processing unit that identifies a naming rule for information included in a first code from specification information indicating a Web API (Application Programming Interface) specification and the first code generated based on the Web API specification, and generates a source file to which a second code processed in the first code is added based on the naming rule. [[Brief Description of the Drawings]]

[0006] [Figure 1] A diagram showing an example of the functional configuration of the information processing device according to the first embodiment. [Figure 2] A diagram showing an example of a Web API specification for the first embodiment. [Figure 3] A figure showing an example of the first code of the first embodiment. [Figure 4] A diagram showing an example of the naming convention for the first embodiment. [Figure 5] A figure showing an example of the second code of the first embodiment. [Figure 6] A flowchart illustrating an example of the information processing method of the first embodiment. [Figure 7] A diagram showing an example of the functional configuration of the information processing device according to the second embodiment. [Figure 8] A diagram showing an example of the linking information in the second embodiment. [Figure 9] A diagram showing an example of the third code of the second embodiment. [Figure 10] A flowchart illustrating an example of the information processing method of the second embodiment. [Figure 11] A diagram showing an example of the functional configuration of the information processing device according to the third embodiment. [Figure 12] A diagram showing an example of group information in the third embodiment. [Figure 13] A diagram showing an example of the second code of the third embodiment. [Figure 14] A diagram showing an example of the third code of the third embodiment. [Figure 15] A flowchart illustrating an example of the information processing method of the third embodiment. [Figure 16] A diagram showing an example of the functional configuration of the information processing device according to the fourth embodiment. [Figure 17] A figure showing an example of a response sample of the fourth embodiment. [Figure 18] A diagram showing an example of the second code of the fourth embodiment. [Figure 19] A flowchart illustrating an example of the information processing method of the fourth embodiment. [Figure 20] A diagram showing an example of the functional configuration of the information processing device according to the fifth embodiment. [Figure 21] A diagram showing an example of API specification differences in the fifth embodiment. [Figure 22] Figure illustrating an example of a second code according to the fifth embodiment. [Figure 23] Flowchart illustrating an example of an information processing method according to the fifth embodiment. [Figure 24] Figure illustrating an example of the hardware configuration of an information processing apparatus according to the first to fifth embodiments. MODE FOR CARRYING OUT THE INVENTION

[0007] Embodiments of an information processing apparatus, an information processing method, and a program will be described in detail below with reference to the accompanying drawings.

[0008] Utilizing openapi-generator can be expected to improve development efficiency, but the skeleton code output by openapi-generator does not include the processing to be executed when a Web API is called. Therefore, a developer needs to additionally write the processing to be executed separately, but API specifications are prone to changes.

[0009] Specifically, when openapi-generator generates skeleton code, it overwrites and saves all files in the specified directory. For this reason, when there is a change in the Web API specification, outputting new skeleton code again with openapi-generator results in the processing (source code) additionally written by the developer being deleted every time, creating a new burden on the developer to additionally write the same processing again.

[0010] Furthermore, even if the output destination directory of openapi-generator is set to another location to avoid overwriting, the developer still needs to transfer the code they have additionally written so far to the newly output skeleton code, so the burden on the developer is not reduced.

[0011] In the following embodiments, an embodiment of an information processing apparatus that can reduce the burden on developers creating source code based on Web API specification information will be described.

[0012] (First Embodiment) First, an example of the functional configuration of the information processing device of the first embodiment will be described.

[0013] [Example of functional configuration] Figure 1 shows an example of the functional configuration of the information processing device 2 of the first embodiment. The information processing device 2 includes a processing unit 21 and a naming convention DB 22.

[0014] The processing unit 21 is implemented by at least one processing unit and executes the processing of the information processing unit 1. This processing unit includes, for example, a control unit and an arithmetic unit, and is implemented by analog or digital circuits. The processing unit may be a central processing unit (CPU), a general-purpose processor, a microprocessor, a digital signal processor (DSP), an ASIC (Application Specific Integrated Circuit), an FPGA (Field-Programmable Gate Array), or a combination thereof.

[0015] The processing unit 21 includes a specific unit 211 and a second code generation unit 212.

[0016] The specific unit 211 reads the Web API specification and the first code.

[0017] Figure 2 shows an example of a Web API specification for the first embodiment. As shown in Figure 2, a Web API specification (an example of specification information) is data that shows the specifications of a Web API.

[0018] Returning to Figure 1, the first code is the code generated by the first code generator 1 from the Web API specification.

[0019] For example, the first code generator 1 is a skeleton code generator on which an automatic source code generation tool such as openapi-generator operates.

[0020] For example, the first code is skeleton code. Skeleton code is source code that includes function definitions but does not describe the processing that uses those functions. Specifically, skeleton code is source code generated from the Web API specification that describes only the program framework and function definitions. Skeleton code does not describe the specific processing that will be executed (the processing that will be executed when the Web API is called), and the processing intended based on the Web API specification cannot be performed with skeleton code alone.

[0021] The identification unit 211 identifies the naming convention for the function name of the first function included in the first code and the file name of the file in which the first function is stored, based on the Web API specification and the first code created based on the Web API specification. Specifically, the identification unit 211 identifies the naming convention for the function name of the first function and the file name of the first function by comparing the input and output of the skeleton code generator (input: Web API specification, output: first code). In other words, the identification unit 211 identifies the naming convention for the function name of the first function and the file name of the first function by comparing the keywords included in the Web API specification with the function name of the first function and the file name of the first function.

[0022] Naming conventions are rules that indicate a correspondence between the Web API specification and the initial code (e.g., skeleton code). For example, the naming convention for function names included in the skeleton code generated by openapi-generator from the OpenAPI Specification (OAS) uses the operationId from the OAS.

[0023] The specific unit 211 stores the naming rules in the naming rules DB 22. The naming rules DB 22 is stored in a storage device. The storage device is, for example, a main memory such as RAM (Random Access Memory) and an auxiliary storage device such as an HDD (Hard Disk Drive). The naming rules DB 22 may also be stored in a storage device outside the information processing device 2.

[0024] Figure 3 shows an example of the first code of the first embodiment. The example in Figure 3 shows that the first code is skeleton code that does not describe specific processing details.

[0025] Figure 4 shows an example of the naming convention of the first embodiment. v1 and v2 indicate versions of the first code. The version of the first code changes as the first code is updated. The naming convention is stored for each version of the first code.

[0026] In the example in Figure 4, for instance, the following naming convention shows that the operationId entry in the Web API specification is used to generate the function name, and that the notation of the function name changes from camel case to snake case for the operationId entry. from: operationId, to: function_name, rule: Camel case -> Snake case

[0027] Specifically, this naming convention identifies that the function name `list_pets` in Figure 2 is generated from the `operationId: listPets` in Figure 2.

[0028] For example, the following naming convention indicates that the tags (an example of keywords included in the specification information) in the Web API specification are used to generate the filename of the file where the first function included in the first code is stored, and the filename is generated by combining the tags with "_controller.py". form: Tag, to: skeltoncode_filename, rule: concat “_controller.py”

[0029] Specifically, this naming convention identifies that the file pets_controller.py, as shown in Figure 2, is generated from tags:pets in Figure 2.

[0030] Returning to Figure 1, the second code generation unit 212 generates a source file (for example, a developer file) in which the second code processed in the first code is appended, based on the naming convention. The second code is code that indicates the processing content to be appended by the developer. Specifically, the second code is code that contains the specific processing content processed in the first code, and includes a second function with a function name based on the naming convention.

[0031] Figure 5 shows an example of the second code of the first embodiment. The example in Figure 5 shows the specific processing content of the do_list_pets function (the process of calculating r_value and returning r_value). The second code is, for example, data for the developers of the first code. The second function included in the second code shows the specific processing that is executed within the first function, as shown in the example of the do_list_pets function in Figure 5.

[0032] The second code defines a second function with a function name based on a naming convention, as well as a file name based on the naming convention, and includes information that can be reused even if the Web API version changes in the future. For example, the reusable information is the processing details of the second code that were added by developers in previous versions.

[0033] Figure 6 is a flowchart showing an example of the information processing method of the first embodiment. First, the identification unit 211 reads the Web API specification (an example of specification information) and the first code generated based on the Web API specification (step S1).

[0034] Next, the identification unit 211 identifies the naming conventions for the information contained in the first code (for example, the function name and file name mentioned above) from the Web API specification and the first code read in step S1 (step S2).

[0035] Next, the second code generation unit 212 generates a source file (for example, a developer file) to which the second code processed in the first code is appended, based on the naming convention identified in step S2 (step S3).

[0036] As explained above, the information processing device 2 of the first embodiment can reduce the burden on developers who create source code based on Web API specification information. Specifically, the information processing device 2 of the first embodiment can automatically generate source files for second code (for example, processing described in the developer file) that are added to the first code (for example, skeleton code) from the Web API specification. This reduces the development burden on developers, for example, even if the number of Web APIs increases. For example, the function name of the second function in the second code based on the naming convention can be reused even if the Web API specification changes, as long as the naming convention does not change.

[0037] (Second Embodiment) Next, a second embodiment will be described. In the description of the second embodiment, explanations similar to those of the first embodiment will be omitted, and the differences from the first embodiment will be explained. In the second embodiment, an embodiment in which a third code is generated from a first code and a second code will be described.

[0038] [Example of functional configuration] Figure 7 shows an example of the functional configuration of the information processing device 2-2 in the second embodiment. The information processing device 2-2 includes a processing unit 21-2, a naming convention DB 22, and a linking DB 23.

[0039] The processing unit 21-2 is implemented by at least one processing unit, similar to the first embodiment. The naming convention DB22 and the association DB23 are stored in a storage device similar to the first embodiment.

[0040] The processing unit 21-2 includes a specification unit 211, a second code generation unit 212, a linking unit 213, and a third code generation unit 214. The specification unit 211 and the second code generation unit 212 in the second embodiment are the same as those in the first embodiment, so their description is omitted.

[0041] The linking unit 213 links the first code and the second code and stores the linking information indicating the correspondence between the first code and the second code in the linking DB 23. Specifically, the linking unit 213 reads the first code (Figure 3), the naming convention (Figure 4), and the second code (Figure 5), and associates the function name of the second function included in the second code with the function name of the first function included in the first code.

[0042] The third code generation unit 214 generates the third code from the first code and the second code based on the linking information. For example, the third code generation unit 214 generates the third code by merging (integrating) the first code and the second code based on the linking information. For example, the third code is source code that can be released as source code used to operate the actual service.

[0043] Furthermore, the third code automatically processed by the third code generation unit 214 may be modified or changed by the developer as appropriate before release.

[0044] Figure 8 shows an example of linking information in the second embodiment. Figure 9 shows an example of the third code in the second embodiment. The third code generation unit 214 uses the linking information (Figure 8) to rewrite the corresponding part of the first code (Figure 3) to a process that calls the second function described in the second code (Figure 5), and automatically generates releaseable source code (Figure 9).

[0045] In the example in Figure 8, the following two lines show the file name and function name of the second code. developFile: dev_list_pets.py develop: do_list_pets,

[0046] Additionally, the following two lines show the filename and function name of the first code. skeletonFile: pets_controller.py skelton: list_pets,

[0047] Furthermore, the following two lines indicate that 'do some magic!' in the first code should be replaced with 'do_list_pets', and that 'import developFile' should be added to the first code. replace: return 'do some magic!' add: import developFile

[0048] Additionally, the following two lines show the filename and function name of the second code. developFile: dev_create_pets.py develop: do_create_pets,

[0049] Additionally, the following two lines show the filename and function name of the first code. skeletonFile: pets_controller.py skelton: create_pets,

[0050] Additionally, the following two lines indicate that line 13 of the first code should be replaced with do_create_pets, and that import developFile should be added to the first code. Replace: L13 add: import developFile

[0051] Figure 10 is a flowchart showing an example of the information processing method of the second embodiment. Steps S11 to S13 are the same as steps S1 to S3 of the first embodiment, so their explanation is omitted. The source file generated by the processing of the second code generation unit 212 in step S3 is, for example, a developer file on which the second code is added by the developer.

[0052] The linking unit 213 links the first code and the second code, generates linking information indicating the correspondence between the first code and the second code, and stores the linking information in the linking DB 23 (step S14).

[0053] Next, the third code generation unit 214 generates a third code from the first code and the second code based on the linking information generated in step S14 (step S15).

[0054] According to the second embodiment, the process of calling the second code (for example, a second function containing specific processing details described in a developer file) from the first code (for example, skeleton code) can be automatically generated. This reduces the developer's work to, for example, only adding to the developer file, thereby reducing the burden of system development.

[0055] (Third embodiment) Next, the third embodiment will be described. In the description of the third embodiment, explanations similar to those of the first and second embodiments will be omitted, and the differences from the first and second embodiments will be described.

[0056] In the first and second embodiments described above, if multiple second code files (second functions containing specific processing details) are generated for a single Web API path, for example, as template files for multiple developers, the number of template files increases, making management cumbersome.

[0057] Therefore, in the third embodiment, we will describe an embodiment in which each Web API in the Web API specification is grouped, and the second code generated from the Web APIs in the same group is output to the same file.

[0058] [Example of functional configuration] Figure 11 shows an example of the functional configuration of the information processing device 2-3 of the third embodiment. The information processing device 2-3 includes a processing unit 21, a naming convention DB 22, a linking DB 23, and a group information DB 24. In Figure 11, the linking DB 23 is omitted to avoid complexity, but the linking DB 23 is the same as in the second embodiment.

[0059] The processing unit 21-3 is implemented by at least one processing unit, similar to the first embodiment. The group information DB24 is stored in a storage device similar to the first embodiment.

[0060] The processing unit 21-3 includes a specific unit 211, a second code generation unit 212, a linking unit 213, and a third code generation unit 214. In Figure 11, the linking unit 213 is omitted from the description to avoid complexity, but the linking unit 213 is the same as in the second embodiment.

[0061] Furthermore, the processing of the third code generation unit 214 is the same as in the second embodiment. The following description will focus on the differences between the operation of the first and second embodiments described above.

[0062] The identification unit 211 identifies the naming conventions for function names and file names included in the first code from the Web API specification and the first code, and stores the naming conventions in the naming convention DB 22.

[0063] Furthermore, the identification unit 211 stores group information in the group information DB 24. Specifically, the identification unit 211 calculates the similarity of elements (keywords) written in the Web API specification and generates group information based on the similarity.

[0064] For example, the identification unit 211 calculates the similarity based on whether the tags are the same. The identification unit 211 registers elements with the same tag as belonging to the same group in the group information DB 24.

[0065] For example, the identification unit 211 calculates similarity based on the degree of overlap of the strings included in the path. The identification unit 211 registers Web APIs whose path strings are the same for N characters (where N is any natural number) or more (Web APIs with N characters or more overlap) as the same group in the group information DB 24.

[0066] The second code generation unit 212 generates source files to which the second code will be appended, based on the naming convention DB 22 and the group information DB 24. The second code generation unit 212 outputs the processing (second code) of functions corresponding to Web APIs of the same group into a single file. That is, when the second code generation unit 212 generates a source file containing multiple second functions, it outputs the second functions, each having a function name generated based on the naming convention identified from keywords of the same group based on the group information, into the same source file.

[0067] Figure 12 shows an example of group information in the third embodiment. Figure 12 is an example of group information that shows that Web APIs whose tags are "pets" are grouped as "pets", and functions included in the "pets" group are output to the dev_pets.py file.

[0068] Figure 13 shows an example of the second code for the third embodiment. Figure 13 shows an example in which the functions do_create_pets and do_list_pets, which are included in the pets group, are output in the same dev_pets.py file.

[0069] Figure 14 shows an example of the third code in the third embodiment. Figure 14 shows an example in which the functions do_create_pets and do_list_pets are imported from a single file dev_pets by from dev_pets import do_create_pets, do_list_pets.

[0070] Figure 15 is a flowchart showing an example of the information processing method of the third embodiment. Steps S21 and S22 are the same as steps S1 and S2 of the first embodiment, so their explanation is omitted.

[0071] The specific unit 211 generates the group information described above and stores the group information in the group DB 24 (step S23).

[0072] Next, the second code generation unit 212 generates a source file to which the second code will be appended (for example, a developer file) based on the naming convention identified in step S22 and the group information generated in step S23 (step S24).

[0073] Steps S25 and S26 are the same as steps S14 and S15 of the second embodiment, so their description is omitted.

[0074] As explained above, according to the third embodiment, Web APIs (second functions of the second code) of the same group are output to the same source file, thereby reducing the number of source files (e.g., developer files) that store the second code and reducing the complexity of management. This reduces the need for developers to open multiple source files and the effort required to find the second function to be edited from multiple source files, which is expected to lower development costs.

[0075] (Fourth Embodiment) Next, the fourth embodiment will be described. In the description of the fourth embodiment, explanations similar to those of the first and second embodiments will be omitted, and the differences from the first and second embodiments will be described. In the fourth embodiment, an embodiment will be described in which a template process showing an example of processing is included in the source file to which the second code is added.

[0076] [Example of functional configuration] Figure 16 shows an example of the functional configuration of the information processing device 2-4 of the fourth embodiment. The information processing device 2-4 includes a processing unit 21, a naming convention DB 22, a linking DB 23, and a response sample DB 25. In Figure 16, the linking DB 23 is omitted to avoid complexity, but the linking DB 23 is the same as in the second embodiment.

[0077] The processing unit 21-4 is implemented by at least one processing unit, similar to the first embodiment. The response sample DB25 is stored in a storage device similar to the first embodiment.

[0078] The processing unit 21-4 includes a specific unit 211, a second code generation unit 212, a linking unit 213, and a third code generation unit 214. In Figure 16, the linking unit 213 is omitted from the description to avoid complexity, but the linking unit 213 is the same as in the second embodiment.

[0079] The identification unit 211 identifies the naming conventions for function names and file names included in the first code from the Web API specification and the first code, and stores the naming conventions in the naming convention DB 22.

[0080] Furthermore, the specific unit 211 stores the response sample in the response sample DB 25. The Web API specification may contain example responses when the Web API (first function) is called. If the specific unit 211 contains example responses in the Web API specification, it stores those example responses as response samples in the response sample DB 25.

[0081] The second code generation unit 212 generates source files to which the second code will be appended, based on the naming convention DB22 and the response sample DB25. For Web APIs (first functions) that have response samples, the second code generation unit 212 generates a second function that includes the response samples.

[0082] Figure 17 shows an example of a response sample in the fourth embodiment. Figure 17 shows an example where the response examples of listPets are listed as responses. In the example in Figure 17, the API status code and the response data set are stored as a response sample.

[0083] Figure 18 shows an example of the second code of the fourth embodiment. Figure 18 shows an example of the do_list_pets function including the value of the response r_value, as shown below. r_value=[{“id”:0,“name”:“name”,“tag”:“tag”}]

[0084] The second code generation unit 212 identifies the value of the response r_value based on the response sample DB 25 and generates the do_list_pets function (second code) which includes the value of the response r_value.

[0085] Figure 19 is a flowchart showing an example of the information processing method of the fourth embodiment. Steps S31 and S32 are the same as steps S1 and S2 of the first embodiment, so their explanation is omitted.

[0086] The specific unit 211 obtains the above-mentioned response sample from the Web API specification and stores the response sample in the response sample DB 25 (step S33).

[0087] Next, the second code generation unit 212 generates a source file (for example, a developer file) to which the second code will be appended, based on the naming convention identified in step S32 and the response sample obtained in step S33, and appends the response example to the source file (step S34).

[0088] Steps S35 and S36 are the same as steps S14 and S15 of the second embodiment, so their description is omitted.

[0089] As explained above, in the fourth embodiment, if the Web API specification includes an example response when the Web API is called, the process of executing that example response as the Web API response is pre-written in the source file to which the second code is added (for example, the developer file). In other words, a system that returns a response message in the actual service can be created without the developer having to do any development work. This allows developers to work on developing, for example, client applications that require Web API responses in parallel, thereby reducing the burden on developers.

[0090] (Fifth embodiment) Next, the fifth embodiment will be described. In the description of the fifth embodiment, explanations similar to those of the first embodiment will be omitted, and the differences from the first embodiment will be described.

[0091] The Web API specification is expected to be updated for various reasons, such as the addition of arguments and the addition of new APIs. In the first to fourth embodiments described above, a new second code was created based on the Web API specification, which resulted in the problem that had existed in the past—that the code for the processing to be executed that the developer added was deleted each time, creating a new burden for the developer to add the same processing again—applying to the source file that stores the second code.

[0092] In the fifth embodiment, we describe an embodiment in which, even when the Web API specification is updated, the source files containing the second code (for example, developer files) are not completely overwritten, but only the differences are partially overwritten.

[0093] [Example of functional configuration] Figure 20 shows an example of the functional configuration of the information processing device 2-5 of the fifth embodiment. The information processing device 2-5 includes a processing unit 21, a naming convention DB 22, a linking DB 23, and an API specification difference DB 26. In Figure 20, the linking DB 23 is omitted to avoid complexity, but the linking DB 23 is the same as in the second embodiment.

[0094] The processing unit 21-5 is implemented by at least one processing unit, similar to the first embodiment. The API specification difference DB 26 is stored in a storage device similar to the first embodiment.

[0095] The processing unit 21-5 includes a specific unit 211, a second code generation unit 212, a linking unit 213, and a third code generation unit 214. In Figure 20, the linking unit 213 is omitted from the description to avoid complexity, but the linking unit 213 is the same as in the second embodiment.

[0096] The identification unit 211 identifies the naming conventions for function names and file names included in the first code from the Web API specification and the first code, and stores the naming conventions in the naming convention DB 22.

[0097] Furthermore, the specific unit 211 stores the API specification differences in the API specification difference DB 26. When a Web API specification is updated, the specific unit 211 obtains the difference information of the Web API specification and stores it in the API specification difference DB 26. For example, updates to Web API specifications are managed by version. When the version of a Web API specification is updated, the specific unit 211 obtains the API specification difference, which shows the difference in the Web API specification due to the version update.

[0098] For example, to obtain the differences in Web API specifications, the `git diff` command can be used if the project is managed with Git. Alternatively, if the Web API specification files are copied and version-controlled, the `diff` command can be used to obtain the differences in the file contents.

[0099] Note that the method for obtaining the differences in the Web API specification is not limited to the example above; any method that can obtain the differences is acceptable.

[0100] The above API specification differences are information indicating the differences between the Web API specification before and after the changes. The second code generation unit 212 combines the API specification differences with the naming conventions described above to identify the difference code to be added to or deleted from the source file (for example, a developer file) in which the second code is written, and generates the second code with the difference code added or deleted.

[0101] Figure 21 shows an example of API specification differences in the fifth embodiment. In the example in Figure 21, for example, the differences in version 1 are stored using diff. Since version 1 is newly created, the differences are the entire API specification. Also, for example, the differences between version 1 and 2 are stored using diff, based on the results obtained from the git diff command or the diff command.

[0102] Figure 22 shows an example of the second code in the fifth embodiment. In the example in Figure 22, description 101 is added based on the API specification difference between version 1 and 2. Also, description 102 is the second code written by the developer in version 1, but it is not deleted even when updated from version 1 to 2.

[0103] Figure 23 is a flowchart showing an example of the information processing method of the fifth embodiment. Steps S51 and S52 are the same as steps S1 and S2 of the first embodiment, so their explanation is omitted.

[0104] The specific unit 211 obtains the API specification difference described above and stores the API specification difference in the API specification difference DB 26 (step S53).

[0105] Next, the second code generation unit 212 generates a source file to which the second code will be added (for example, a developer file) based on the naming convention identified in step S52 and the API specification differences obtained in step S53 (step S54). Specifically, the second code generation unit 212 of the fifth embodiment identifies the difference code to be added to or deleted from the second code based on the API specification differences and generates a source file containing the second code with the added or deleted difference code.

[0106] Steps S55 and S56 are the same as steps S14 and S15 of the second embodiment, so their description is omitted.

[0107] As described above, the identification unit 211 and the second code generation unit 212 of the fifth embodiment add or delete the differences in the Web API specification to the source file in which the second code is written. As a result, when a developer updates the Web API specification, they only need to add the logic processing for the updated Web API to the source file in which the second code is written (for example, the developer's file), thereby reducing the burden on the developer when updating the Web API specification.

[0108] Finally, we will describe examples of the hardware configurations of the information processing devices 2 to 2-5 of the first to fifth embodiments.

[0109] [Example hardware configuration] Figure 24 shows examples of the hardware configurations of information processing devices 2 to 2-5 according to the first to fifth embodiments. The information processing devices 2 to 2-5 include a processor 201, a main memory 202, an auxiliary storage device 203, a display device 204, an input device 205, and a communication device 206. The processor 201, the main memory 202, the auxiliary storage device 203, the display device 204, the input device 205, and the communication device 206 are connected via a bus 210.

[0110] Note that information processing devices 2 to 2-5 may not be equipped with some of the above configurations. For example, if information processing devices 2 to 2-5 can utilize the input and display functions of an external device, information processing device 1 may not be equipped with a display device 204 and an input device 205.

[0111] The processor 201 executes the program read from the auxiliary storage device 203 into the main memory device 202. The main memory device 202 is memory such as ROM and RAM. The auxiliary storage device 203 is such as an HDD and memory card.

[0112] The display device 204 is, for example, a liquid crystal display. The input device 205 is an interface for operating the information processing device 1. The display device 204 and the input device 205 may be implemented by a touch panel or the like that has both display and input functions. The communication device 206 is an interface for communicating with other devices.

[0113] For example, programs executed by information processing devices 2 to 2-5 are provided as computer program products, recorded in installable or executable file format on computer-readable storage media such as memory cards, hard disks, CD-RWs, CD-ROMs, CD-Rs, DVD-RAMs, and DVD-Rs.

[0114] Alternatively, for example, the programs executed by the information processing devices 2 to 2-5 may be stored on a computer connected to a network 200 such as the Internet, and provided by being downloaded via the network 200.

[0115] Alternatively, for example, the information processing devices 2 to 2-5 may be configured to provide programs via a network 200 such as the Internet without requiring downloads. Specifically, the information processing may be executed by a so-called ASP (Application Service Provider) type service, where the server computer does not transfer programs, but only issues execution instructions and retrieves results to realize the processing function.

[0116] Alternatively, for example, the programs for the information processing devices 2 to 2-5 may be pre-installed and provided in ROM or the like.

[0117] The programs executed by the information processing devices 2 to 2-5 are configured as modules that include functions that can also be implemented by programs, as described above. In actual hardware terms, each of these functions is loaded onto the main memory 202 when the processor 201 reads and executes a program from the storage medium. In other words, each of these function blocks is generated on the main memory 202.

[0118] Furthermore, some or all of the above-mentioned functions may be implemented using hardware such as ICs (Integrated Circuits) instead of software.

[0119] Alternatively, multiple processors 201 may be used to implement each function, in which case each processor 201 may implement one of the functions, or two or more of the functions.

[0120] While several embodiments of the present invention have been described, these embodiments are presented as examples only and are not intended to limit the scope of the invention. These novel embodiments can be carried out in a variety of other forms, and various omissions, substitutions, and modifications can be made without departing from the spirit of the invention. These embodiments and their variations are included in the scope and spirit of the invention, as well as in the claims of the invention and its equivalents.

[0121] (Note) Furthermore, the above embodiments can be summarized in the following technical proposal.

[0122] Technical proposal 1 From specification information indicating the Web API (Application Programming Interface) specification, and the first code generated based on the said Web API specification, the naming convention for the information contained in the first code is identified. A processing unit that generates a source file to which the second code processed in the first code is appended, based on the naming convention, An information processing device equipped with the following features. Technical proposal 2 The information contained in the first code includes the function name of the first function contained in the first code, The processing unit identifies the naming convention for the function name of the first function by comparing the keywords included in the specification information with the function name of the first function. The second code includes a second function having a function name based on the naming convention, Information processing device as described in Technical Proposal 1. Technical proposal 3 The processing unit generates association information that links the function name of the first function with the function name of the second function based on the naming convention. Based on the aforementioned linking information, a third code is generated by integrating the first code and the second code. Information processing device as described in Technical Proposal 2. Technical proposal 4 If the specification information includes an example response of the first function, the processing unit shall acquire the example response as a response sample. The response sample is described in the second function, which is associated with the first function that contains the response sample. Information processing device as described in Technical Proposal 3. Technical proposal 5 The first code is a skeleton code that includes the definition of the first function but does not describe the processing using the first function. The second function included in the second code demonstrates the processing using the first function. An information processing device as described in any one of Technical Proposals 2 to 4. Technical plan 6 The information contained in the first code includes the file name of the file in which the first function is stored, The processing unit identifies the naming convention for the file name of the file in which the first function is stored by comparing the keywords included in the specification information with the file name of the file in which the first function is stored. An information processing device as described in any one of Technical Proposals 2 to 5. Technical proposal 7 The processing unit calculates the similarity of the keywords, Based on the similarity, group information for the keywords is generated. When generating the source file containing multiple second functions, the second functions having function names generated based on naming conventions identified from keywords within the same group, based on the group information, are output to the same source file. An information processing device as described in any one of Technical Proposals 2 to 6. Technical proposal 8 The aforementioned keyword is the tag of the first function included in the specification information, The similarity is calculated based on whether the tags are identical or not. Information processing device as described in Technical Proposal 7. Technical proposal 9 The aforementioned keyword is the path of the first function included in the specification information, The similarity is calculated based on the degree of overlap of the strings included in the path. Information processing device as described in Technical Proposal 7. Technical proposal 10 Updates to the aforementioned specification information are managed by version. When the version of the specification information is updated, the processing unit obtains the API specification difference, which indicates the difference in the specification information due to the version update. Based on the API specification differences, identify the difference code to be added to or deleted from the source file, and generate the source file with the added or deleted difference code. An information processing device as described in any one of Technical Proposals 1 to 9. Technical proposal 11 The information processing device identifies the naming convention for the information contained in the first code from specification information indicating the Web API (Application Programming Interface) specification and the first code generated based on the Web API specification. The information processing device generates a source file on which the second code processed in the first code is appended, based on the naming convention. Information processing methods. Technical proposal 12 On the computer, From specification information indicating the Web API (Application Programming Interface) specification, and the first code generated based on the said Web API specification, the naming convention for the information contained in the first code is identified. The source file to which the second code processed in the first code is appended is generated based on the naming convention. program. [Explanation of symbols]

[0123] 1. First Code Generator 2. Information Processing Device 21 Processing Unit 22 Naming convention DB 23 Linked DB 24 Group Information Database 25 Response Sample DB 26 API Specification Difference Database 201 Processor 202 Main storage 203 Auxiliary storage device 204 Display device 205 Input device 206 Communication equipment 210 Bus 211 Specific section 212 Second Code Generation Unit 213 Linking section 214 Third Code Generation Unit

Claims

1. From specification information indicating the Web API (Application Programming Interface) specification, and the first code generated based on the said Web API specification, the naming convention for the information contained in the first code is identified. A processing unit that generates a source file to which the second code processed in the first code is appended, based on the naming convention, An information processing device equipped with the following features.

2. The information contained in the first code includes the function name of the first function contained in the first code, The processing unit identifies the naming convention for the function name of the first function by comparing the keywords included in the specification information with the function name of the first function. The second code includes a second function having a function name based on the naming convention, The information processing apparatus according to claim 1.

3. The processing unit generates association information that links the function name of the first function with the function name of the second function based on the naming convention. Based on the aforementioned linking information, a third code is generated by integrating the first code and the second code. The information processing apparatus according to claim 2.

4. If the specification information includes an example response of the first function, the processing unit shall acquire the example response as a response sample. The response sample is described in the second function, which is associated with the first function that contains the response sample. The information processing apparatus according to claim 3.

5. The first code is a skeleton code that includes the definition of the first function but does not describe the processing using the first function. The second function included in the second code shows the processing using the first function. The information processing apparatus according to any one of claims 2 to 4.

6. The information contained in the first code includes the file name of the file in which the first function is stored, The processing unit identifies the naming convention for the file name of the file in which the first function is stored by comparing the keywords included in the specification information with the file name of the file in which the first function is stored. The information processing apparatus according to any one of claims 2 to 4.

7. The processing unit calculates the similarity of the keywords, Based on the similarity, group information for the keywords is generated. When generating the source file containing multiple second functions, the second functions having function names generated based on naming conventions identified from keywords within the same group, based on the group information, are output to the same source file. The information processing apparatus according to any one of claims 2 to 4.

8. The keyword is the tag of the first function included in the specification information, The similarity is calculated based on whether the tags are the same or not. The information processing apparatus according to claim 7.

9. The keyword is the path of the first function included in the specification information, The similarity is calculated based on the degree of overlap of the strings contained in the path. The information processing apparatus according to claim 7.

10. Updates to the aforementioned specification information are managed by version. When the version of the specification information is updated, the processing unit obtains the API specification difference indicating the difference in the specification information due to the version update. Based on the API specification differences, identify the difference code to be added to or deleted from the source file, and generate the source file with the added or deleted difference code. The information processing apparatus according to claim 1.

11. The information processing device identifies the naming convention for the information contained in the first code from specification information indicating the Web API (Application Programming Interface) specification and the first code generated based on the Web API specification. The information processing device generates a source file on which the second code processed in the first code is appended, based on the naming convention. Information processing methods.

12. On the computer, From specification information indicating the Web API (Application Programming Interface) specification, and the first code generated based on the Web API specification, the naming convention for the information contained in the first code is identified. The source file to which the second code processed in the first code is appended is generated based on the naming convention. program.

Images