Interface design method and system suitable for rail transit engineering geological data interaction

Abstract

The invention discloses an interface design method and system suitable for rail transit engineering geological data interaction, and the method comprises the steps: defining key information defined by an interface, including an interface name, a request parameter and a return parameter; defining related specification constraints of interface development, including interface protocol and standard requirements, interface version specification agreement, state code return and error processing, and data type coding; and on the basis of the determined key information defined by the interface and related specification constraints of interface development, in combination with service requirements, completing interface design suitable for rail transit engineering geological data interaction. Through reasonable interface design, efficient transmission and sharing of geological data can be realized, multi-specialty cooperative work is promoted, and powerful support is provided for construction and operation of rail transit engineering.

Description

Technical Field

[0001] The present invention relates to the technical field of rail transit engineering, and particularly relates to an interface design method and system suitable for the interaction of geological data in rail transit engineering. Background Art

[0002] With the rapid development of rail transit engineering construction, the collection, processing, analysis and application of geological data play a crucial role in the whole life cycle of the project. In order to improve the efficiency of geological data processing in rail transit engineering, ensure the accurate transmission and sharing of data, and promote collaborative work among multiple specialties, it is particularly important to design an interface suitable for the interaction of geological data in rail transit engineering.

[0003] The design of the interface for the interaction of geological data in rail transit engineering faces multiple technical requirements and challenges. First of all, the sources of geological data are diverse, including regional geological data, hydrogeological data, geological disaster data, etc. These data have differences in formats, precisions, storage methods, etc., and the interface is required to be compatible with and process various types of data. Secondly, rail transit engineering involves the cooperation of multiple professional fields, such as design, geology, civil engineering, track, engineering geology, etc. The requirements and processing methods of each specialty for geological data are different, and the interface design needs to ensure that data can be transmitted and shared efficiently and accurately among different specialties. In addition, with the development of technology, the data interaction interface also needs to have scalability and flexibility to adapt to new technologies, new standards and new requirements that may emerge in the future.

[0004] Therefore, an interface design suitable for the interaction of geological data in rail transit engineering is very necessary. The main objectives of the interface design mainly include the following aspects: one is to achieve the standardized transmission of data. By defining unified data formats, coding rules and transmission protocols, seamless docking of data among different systems and different platforms is ensured; the second is to improve the data transmission efficiency and security. By adopting efficient data compression algorithms and encryption technologies, the transmission cost is reduced and the data security is guaranteed; the third is to enhance the scalability and flexibility of the interface, support the access of new types of data and the expansion of new functions to adapt to the development and changes of future technologies; the fourth is to promote collaborative work among multiple specialties. Through the interface, the deep integration and sharing of geological data and other specialty data are realized, and the overall work efficiency and decision-making level are improved.

[0005] In summary, the interface for the interaction of geological data in rail transit engineering is an indispensable part of rail transit engineering construction. Through reasonable interface design, efficient transmission and sharing of geological data can be achieved, collaborative work among multiple specialties can be promoted, and strong support can be provided for the construction and operation of rail transit engineering. Summary of the Invention

[0006] This application provides an interface design method and system suitable for rail transit engineering geological data interaction to solve the problem of interface design for rail transit engineering geological data interaction.

[0007] According to the first aspect, in one embodiment, an interface design method suitable for rail transit engineering geological data interaction is provided. The method includes:

[0008] Clarify the key information of the interface definition, including the interface name, request parameters, and return parameters;

[0009] Clarify the relevant specification constraints for interface development, including interface protocols and standard requirements, interface version specification conventions, status code return and error handling, and data type encoding;

[0010] Based on the determined key information of the interface definition and the relevant specification constraints for interface development, combined with business requirements, complete the interface design suitable for rail transit engineering geological data interaction.

[0011] Furthermore, the interface protocols and standard requirements include gRPC and RESTful protocols;

[0012] For the gRPC protocol:

[0013] Communication method: Use the HTTP / 2 protocol for transmission to maintain two-way communication;

[0014] Request structure: Define the data structure through Protobuf to ensure cross-language compatibility and efficient data serialization;

[0015] Definition file: All interfaces are defined in the.proto file, and include the service methods of the interface, the fields and data types of the input and output messages;

[0016] Interface path: Named in the format of {service}.{method} to ensure the global uniqueness of the interface path;

[0017] Request port: gRPC uses port 8012, and gRPC-WEB uses port 8011;

[0018] For the RESTful protocol:

[0019] Request method: Follow the request methods of the HTTP protocol;

[0020] GET: Used to obtain resources;

[0021] POST: Used to create resources;

[0022] PUT / PATCH: Used to update resources;

[0023] DELETE: Used to delete resources;

[0024] URI Path Design: Define the path using resource names and hierarchical relationships, avoiding the use of verbs;

[0025] Request Header Requirements: Each request must include the content type;

[0026] Return Data Format: Uniformly adopt the JSON format;

[0027] Request Port: Use port 80.

[0028] Furthermore, the interface version specification agreement includes version format and version control.

[0029] Furthermore, the version format adopts the v{major}.{minor} format, where major represents the major version and minor represents the minor version; for major changes, increase the major version number, and for minor changes, increase the minor version number;

[0030] The version control follows the following requirements:

[0031] RESTful Interface: The version number should be included in the URL in the format / api / v{version} / {resource};

[0032] gRPC Interface: The version information should be specified in the service definition of the.proto file.

[0033] Furthermore, the status code return and error handling include gRPC status codes, RESTful status codes, and error handling.

[0034] Furthermore,

[0035] For gRPC status codes, use the built-in gRPC status code definitions for standard error return values:

[0036] OK: The request was successful;

[0037] INVALID_ARGUMENT: The parameters are invalid;

[0038] NOT_FOUND: The resource does not exist;

[0039] ALREADY_EXISTS: The resource already exists;

[0040] PERMISSION_DENIED: No permission;

[0041] UNAUTHENTICATED: Authentication failed;

[0042] INTERNAL: Internal error;

[0043] UNAVAILABLE: The service is unavailable;

[0044] DEADLINE_EXCEEDED: The request timed out;

[0045] The error message contains the error_code and error_message fields. The error_code is the business error code, and the error_message is the detailed error description, which is convenient for client debugging;

[0046] For RESTful status codes, use the HTTP standard status codes to define the return values:

[0047] OK: The request was successful;

[0048] Created: The resource was successfully created;

[0049] No Content: The resource was successfully deleted and no content was returned;

[0050] Bad Request: The client request is invalid;

[0051] Unauthorized: Not authenticated or authentication failed;

[0052] Forbidden: No permission;

[0053] Not Found: The resource was not found;

[0054] Conflict: Resource conflict;

[0055] Internal Server Error: Service internal error;

[0056] The returned error information is in JSON format and contains the error_code and error_message fields for easy client parsing and processing;

[0057] The error handling includes:

[0058] Parameter verification: Perform parameter verification at the earliest stage of request processing and return error information as early as possible;

[0059] Error logging: When the server catches an error, it needs to record the log, including the error code, request ID, and detailed error information for easy troubleshooting;

[0060] Custom error codes: Use fixed rules for application-level error codes for easy tracing.

[0061] Furthermore, the data type encoding includes gRPC data types, RESTful data types and encodings, data specifications, and data size and paging controls.

[0062] Furthermore, for gRPC data types:

[0063] Use the basic types provided by Protobuf to ensure cross-platform compatibility; for complex data types, preferably use message to define complex data structures, avoid structures with too deep nesting, and ensure clarity; define business-related enumeration types in the.proto file to improve code readability and compatibility;

[0064] Field rules: Clearly specify optional, repeated, and map fields to facilitate understanding of the necessity of fields and data structures;

[0065] For RESTful data types and encodings:

[0066] JSON format: All data is encoded in JSON format;

[0067] Numerical values: Uniformly use the number type to avoid converting numerical values to strings when returning JSON;

[0068] Boolean values: Represented by true and false, do not use 1 or 0;

[0069] Dates and times: Adopt the ISO8601 format;

[0070] Enumerations: Represented by strings, avoid using integer numbers to improve readability;

[0071] Encoding specification: Strictly use UTF-8 encoding to avoid parsing exceptions caused by special characters;

[0072] For data specifications:

[0073] Field naming: Adopt camel case naming to improve consistency;

[0074] Null value handling:

[0075] gRPC: Unassigned fields should be empty to reduce the amount of data transmitted;

[0076] RESTful: Null value fields should be omitted or clearly represented as null to indicate no value;

[0077] For data size and paging controls:

[0078] Paging: When returning list data, adopt a paging strategy to avoid returning too much data at once; the paging parameters are uniformly page and pageSize;

[0079] Data limitation: Avoid returning data exceeding the specified size, set an upper limit for the data returned in a single request, and avoid overloading the client or server.

[0080] Furthermore, based on the key information defined for the interface and the relevant specification constraints for interface development, combined with business requirements, complete the interface design applicable to the interaction of rail transit engineering geological data, specifically including:

[0081] The content of the interface design applicable to the interaction of rail transit engineering geological data includes interface name, interface description, interface protocol, interface method, request parameter description, and return parameter description.

[0082] According to the second aspect, in one embodiment, an interface design system applicable to the interaction of rail transit engineering geological data is provided. The system includes:

[0083] The first basic definition module is used to clarify the key information defined for the interface, including the interface name, request parameters, and return parameters;

[0084] The second basic definition module is used to clarify the relevant specification constraints for interface development, including interface protocol and standard requirements, interface version specification conventions, status code return and error handling, and data type encoding;

[0085] The interface design module is used to complete the interface design applicable to the interaction of rail transit engineering geological data based on the determined key information of the interface definition and the relevant specification constraints for interface development, combined with business requirements.

[0086] This application provides an interface design method and system applicable to the interaction of rail transit engineering geological data, which has the following beneficial effects:

[0087] (1) Based on international standards, formulate unified data formats and coding rules to ensure the standardized transmission of data;

[0088] (2) Adopt advanced network communication technologies to achieve efficient data transmission and sharing;

[0089] (3) Design a flexible and extensible interface architecture, support modular development and plug-in expansion, and facilitate the rapid integration and deployment of new functions;

[0090] (4) Strengthen the communication and collaboration among multiple specialties in the field of rail transit engineering. Through interface design, it promotes the information sharing and resource integration of geological data and improves the overall work efficiency. This interface design has a good application prospect in the field of rail transit engineering geological data sharing. BRIEF DESCRIPTION OF THE DRAWINGS

[0091] Figure 1Flowchart of an interface design method for rail transit engineering geological data interaction provided by an embodiment of the present invention;

[0092] Figure 2 Structural schematic diagram of an interface design system for rail transit engineering geological data interaction provided by an embodiment of the present invention. Detailed implementation manners

[0093] The present invention will be further described in detail below in conjunction with the accompanying drawings through specific implementation manners. Similar elements in different implementation manners are labeled with related similar element numbers. In the following implementation manners, many detailed descriptions are provided to enable a better understanding of the present application. However, those skilled in the art can easily recognize that some of the features can be omitted in different situations, or can be replaced by other elements, materials, and methods. In some cases, some operations related to the present application are not shown or described in the specification to avoid overwhelming the core part of the present application with excessive descriptions. For those skilled in the art, it is not necessary to describe these related operations in detail, and they can fully understand the related operations based on the descriptions in the specification and general technical knowledge in the art.

[0094] In addition, the features, operations, or characteristics described in the specification can be combined in any appropriate manner to form various implementation manners. At the same time, the steps or actions in the method description can also be reordered or adjusted in an obvious manner by those skilled in the art. Therefore, the various sequences in the specification and drawings are only for clearly describing a certain embodiment and do not mean that they are necessary sequences, unless it is stated that a certain sequence must be followed.

[0095] An interface design method for rail transit engineering geological data interaction provided by the first embodiment of the present invention will be described in detail below in conjunction with Figure 1 for detailed description.

[0096] As Figure 1 shown, in step S100, key information of the interface definition is clarified, including the interface name, request parameters, and return parameters.

[0097] The above steps specifically include:

[0098] Clarify the interface name, such as GetMapDetailInDB, etc.

[0099] Clarify the request parameters, such as db_id, feature_criteria, table_name, with_sld, etc.

[0100] Specify the return parameters, such as the return data items field_row, value_rows, table_name, srs, sld, etc.

[0101] Such as Figure 1 As shown, in step S100, clarify the relevant specification constraints for interface development, including interface protocols and standard requirements, interface version specification agreements, status code returns and error handling, and data type encoding.

[0102] The above steps specifically include:

[0103] 1. Interface protocols and standard requirements

[0104] The interface adopts gRPC and RESTful protocols and follows the following standard requirements:

[0105] 1.1 gRPC protocol:

[0106] Communication method: Use the HTTP / 2 protocol for transmission to maintain two-way communication.

[0107] Request structure: Define the data structure through Protocol Buffers (Protobuf) to ensure cross-language compatibility and efficient data serialization.

[0108] Definition file: All interfaces are defined in the.proto file, and include the service methods of the interface, the fields and data types of the input and output messages.

[0109] Interface path: Named in the format of {service}.{method}, for example, UserService.GetUser, to ensure the global uniqueness of the interface path.

[0110] Request port: gRPC uses port 8012, and gRPC-WEB uses 8011

[0111] 1.2 RESTful protocol

[0112] Request method: Follow the request methods of the HTTP protocol:

[0113] GET: Used to obtain resources.

[0114] POST: Used to create resources.

[0115] PUT / PATCH: Used to update resources.

[0116] DELETE: Used to delete resources.

[0117] URI Path Design: Use resource names and hierarchical relationships to define paths, avoiding the use of verbs. For example, / api / v1 / users / {userId} / posts represents the list of posts of a user.

[0118] Request Header Requirements: Each request must include Content-Type, such as application / json.

[0119] Return Data Format: Uniformly adopt the JSON format.

[0120] Request Port: Use port 80.

[0121] 2. Interface Version Specification Agreement

[0122] Including agreements on version format, version control, etc.

[0123] 2.1 Version Format: Adopt the format v{major}.{minor}, such as v1.0, where major represents the major version and minor represents the minor version. For major changes (backward-incompatible modifications), increase the major version number; for minor changes (new features, fixing small issues), increase the minor version number.

[0124] 2.2 Version Control Requirements:

[0125] RESTful Interface: The version number should be included in the URL in the format / api / v{version} / {resource}.

[0126] gRPC Interface: The version information should be specified in the service definition of the.proto file, such as service UserServiceV1.

[0127] 3. Status Code Return and Error Handling

[0128] Including gRPC status codes, RESTful status codes, and error handling.

[0129] 3.1 gRPC Status Codes: Use the built-in status codes of gRPC to define standard error return values:

[0130] OK(0): The request was successful.

[0131] INVALID_ARGUMENT(3): The parameters are invalid.

[0132] NOT_FOUND(5): The resource does not exist.

[0133] ALREADY_EXISTS(6): The resource already exists.

[0134] PERMISSION_DENIED(7): No permission.

[0135] UNAUTHENTICATED(16): Authentication failed.

[0136] INTERNAL(13): Internal error.

[0137] UNAVAILABLE(14): Service unavailable.

[0138] DEADLINE_EXCEEDED(4): Request timeout.

[0139] The error message contains the error_code and error_message fields. The error_code is the business error code, and the error_message is the detailed error description for facilitating client debugging.

[0140] 3.2 The return values are defined using HTTP standard status codes for RESTful status codes:

[0141] 200 OK: The request is successful

[0142] 201 Created: The resource is created successfully

[0143] 204 No Content: The resource is deleted successfully, and no content is returned

[0144] 400 Bad Request: The client request is invalid

[0145] 401 Unauthorized: Not authenticated or authentication failed

[0146] 403 Forbidden: No permission

[0147] 404 Not Found: The resource is not found

[0148] 409 Conflict: Resource conflict (such as creating a duplicate of an existing resource)

[0149] 500 Internal Server Error: Service internal error

[0150] The returned error information is in JSON format and contains the error_code and error_message fields for facilitating client parsing and processing.

[0151] 3.3 Error handling includes:

[0152] Parameter verification: Parameter verification is performed at the earliest stage of request processing to return error information as early as possible.

[0153] Error Log: When the server catches an error, it needs to record the log, including the error code, request ID, and detailed error information, which is convenient for troubleshooting.

[0154] Custom Error Codes: Application-level error codes follow fixed rules. For example, 1001 indicates a parameter error, 2001 indicates a database error, etc., for easy tracing.

[0155] 4. Data Type Encoding

[0156] It includes gRPC data types, RESTful data types and encodings, data specifications, and data size and paging controls.

[0157] 4.1 gRPC Data Types

[0158] Use the basic types provided by Protobuf, such as int32, int64, string, bool, to ensure cross-platform compatibility. For complex data types, preferably use message to define complex data structures, avoid overly nested structures, and ensure clarity. Define business-related enumeration types in the.proto file to improve code readability and compatibility.

[0159] Field Rules: Clearly specify optional, repeated, and map fields to facilitate understanding of the necessity of fields and data structures.

[0160] 4.2 RESTful Data Types and Encodings

[0161] JSON Format: All data is encoded in JSON format.

[0162] Numbers: Uniformly use the number type to avoid converting numbers to strings when returning JSON.

[0163] Booleans: Represented by true and false, not 1 or 0.

[0164] Dates and Times: Adopt the ISO8601 format (e.g., YYYY-MM-DDTHH:MM:SSZ).

[0165] Enumerations: Represented by strings to avoid using integer numbers and improve readability.

[0166] Encoding Specification: Strictly use UTF-8 encoding to avoid parsing exceptions caused by special characters.

[0167] 4.3 Data Specifications

[0168] Field Naming: Adopt the camelCase naming convention to improve consistency.

[0169] Null Value Handling:

[0170] gRPC: Unassigned fields should be null to reduce the amount of data transmitted.

[0171] RESTful: Null value fields should be omitted or explicitly represented as null to indicate no value.

[0172] 4.4 Data Size and Pagination Control

[0173] Pagination: When returning list data, a pagination strategy should be adopted to avoid returning too much data at once. The pagination parameters are uniformly page and pageSize.

[0174] Data Limit: Avoid returning data exceeding the specified size. It is recommended to set an upper limit for the data returned in a single request to avoid overloading the client or server.

[0175] As Figure 1 shown, in step S100, based on the key information determined for the interface definition and the relevant specification constraints for interface development, combined with business requirements, the interface design applicable to rail transit engineering geological data interaction is completed.

[0176] Specifically, taking the two-dimensional geological data service interface as an example, the interface design for rail transit geological data interaction mainly includes interfaces such as GetMapDetailInDB, ExportDataInDB, QueryDataInDB, ImportDataToDB, GetMapListWithLevel, GetForeignTableData, DeleteMapInDB, DeleteLayerInDB, DeleteMapDetailInDB, UpdateMapDetailInDB, etc.

[0177] Table 1 GetMapDetailInDB

[0178]

[0179]

[0180] Table 2 ExportDataInDB

[0181]

[0182] Table 3 QueryDataInDB

[0183]

[0184]

[0185] Table 4 ImportDataToDB

[0186]

[0187] Table 5 GetMapListWithLevel

[0188]

[0189] Table 6 GetForeignTableData

[0190]

[0191]

[0192] Table 7 DeleteMapInDB

[0193]

[0194] Table 8 DeleteLayerInDB

[0195]

[0196]

[0197] Table 9 DeleteMapDetailInDB

[0198]

[0199] Table 10 UpdateMapDetailInDB

[0200]

[0201]

[0202] Corresponding to the above-disclosed interface design method applicable to rail transit engineering geological data interaction, an embodiment of the present invention also discloses an interface design system applicable to rail transit engineering geological data interaction, as Figure 2 shown, which specifically includes:

[0203] The first basic definition module is used to clarify the key information of the interface definition, including the interface name, request parameters, and return parameters;

[0204] The second basic definition module is used to clarify the relevant specification constraints for interface development, including interface protocols and standard requirements, interface version specification conventions, status code return and error handling, and data type encoding;

[0205] An interface design module, which is used to complete the interface design applicable to the interaction of rail transit engineering geological data based on the key information of the determined interface definition and the relevant specification constraints of interface development, combined with business requirements.

[0206] It should be noted that for the detailed description of an interface design system applicable to the interaction of rail transit engineering geological data provided in the embodiments of the present invention, reference can be made to the relevant description of an interface design method applicable to the interaction of rail transit engineering geological data provided in the embodiments of the present application, which will not be elaborated here.

[0207] In addition, the embodiments of the present invention further provide an electronic device, which includes: a processor and a memory; the memory is used to store one or more program instructions; the processor is used to run one or more program instructions to execute the steps of an interface design method applicable to the interaction of rail transit engineering geological data as described in any one of the above.

[0208] It should be noted that for the detailed description of an electronic device provided in the embodiments of the present invention, reference can be made to the relevant description of an interface design method applicable to the interaction of rail transit engineering geological data provided in the embodiments of the present application, which will not be elaborated here.

[0209] In addition, the embodiments of the present invention further provide a computer-readable storage medium, on which a computer program is stored, and when the computer program is executed by a processor, it implements the steps of an interface design method applicable to the interaction of rail transit engineering geological data as described in any one of the above.

[0210] It should be noted that for the detailed description of a computer-readable storage medium provided in the embodiments of the present invention, reference can be made to the relevant description of an interface design method applicable to the interaction of rail transit engineering geological data provided in the embodiments of the present application, which will not be elaborated here.

[0211] Those skilled in the art can understand that all or part of the functions of the various methods in the above embodiments can be implemented in a hardware manner or in a computer program manner. When all or part of the functions in the above embodiments are implemented in a computer program manner, the program can be stored in a computer-readable storage medium, which can include: read-only memory, random access memory, magnetic disks, optical disks, hard disks, etc. The above functions can be realized by a computer executing the program. For example, the program is stored in the memory of the device, and when the processor executes the program in the memory, the above-mentioned all or part of the functions can be realized. In addition, when all or part of the functions in the above embodiments are implemented in a computer program manner, the program can also be stored in a storage medium such as a server, another computer, a magnetic disk, an optical disk, a flash drive or a mobile hard disk, and saved to the memory of the local device by downloading or copying, or the system of the local device is updated. When the processor executes the program in the memory, all or part of the functions in the above embodiments can be realized.

[0212] The above uses specific examples to elaborate on the present invention, which is only used to help understand the present invention and is not intended to limit the present invention. For those skilled in the art of the present invention, according to the idea of the present invention, several simple deductions, deformations or substitutions can also be made.

Claims

1. An interface design method applicable to the interaction of engineering geological data for rail transit, characterized in that, The method includes: Identifying the key information of the interface definition, including the interface name, request parameters, and return parameters; Identifying the relevant specification constraints for interface development, including interface protocols and standard requirements, interface version specification conventions, status code return and error handling, and data type encoding; Based on the determined key information of the interface definition and the relevant specification constraints for interface development, combined with business requirements, complete the interface design applicable to rail transit engineering geological data interaction.

2. The interface design method for rail transit engineering geological data interaction according to claim 1, characterized in that The interface protocols and standard requirements include gRPC and RESTful protocols.

3. The interface design method for rail transit engineering geological data interaction according to claim 1, characterized in that, The interface version specification conventions include version format and version control.

4. The interface design method applicable to rail transit engineering geological data interaction according to claim 3, characterized in that The version format adopts the v{major}.{minor} format, where major represents the major version and minor represents the minor version; For major changes, increase the major version number, and for minor changes, increase the minor version number; The version control is in accordance with the following requirements: RESTful interface: The version number should be included in the URL in the format of / api / v{version} / {resource}; gRPC interface: The version information should be specified in the service definition of the.proto file.

5. The interface design method for rail transit engineering geological data interaction according to claim 1, characterized in that, The status code return and error handling include gRPC status codes, RESTful status codes, and error handling.

6. The interface design method applicable to rail transit engineering geological data interaction according to claim 5, characterized in that For gRPC status codes, use the status code definitions built into gRPC to define standard error return values; For RESTful status codes, use HTTP standard status codes to define return values; The error handling includes: Parameter verification: Perform parameter verification at the earliest stage of request processing and return error information as early as possible; Error logging: When the server catches an error, it needs to record the log, including the error code, request ID, and detailed error information for easy troubleshooting; Custom error codes: Use fixed rules for application-level error codes for easy traceability.

7. The interface design method for rail transit engineering geological data interaction according to claim 1, characterized in that, The data type encoding includes gRPC data types, RESTful data types and encoding, data specifications, and data size and pagination control.

8. The interface design method applicable to rail transit engineering geological data interaction according to claim 7, characterized in that The data specifications include: field naming specifications and null value handling specifications; The data size and pagination control: When returning list data, adopt a pagination strategy; set an upper limit for the data returned in a single request to avoid overloading the client or server.

9. The interface design method for rail transit engineering geological data interaction according to claim 1, characterized in that, Based on the determined key information of the interface definition and the relevant specification constraints for interface development, combined with business requirements, complete the interface design applicable to rail transit engineering geological data interaction, specifically including: The content of the interface design applicable to rail transit engineering geological data interaction includes interface name, interface description, interface protocol, interface method, request parameter description, and return parameter description.

10. An interface design system applicable to the interaction of engineering geological data for rail transit projects, characterized in that, The system includes: The first basic definition module is used to identify the key information of the interface definition, including the interface name, request parameters, and return parameters; The second basic definition module is used to clarify the relevant specification constraints for interface development, including interface protocols and standard requirements, interface version specification agreements, status code returns and error handling, and data type encoding; The interface design module is used to complete the interface design applicable to the interaction of engineering geological data for rail transit based on the key information of the determined interface definition and the relevant specification constraints for interface development, combined with business requirements.

Images