Dynamic version control and service management creation method

Abstract

The invention discloses a dynamic version control and service management creation method, which comprises the following steps of: configuring, issuing and updating, firstly requesting a server function configuration interface when an application is started, returning full-amount configuration strategy information when the server receives the request, and requesting according to the configuration strategy information when different function interfaces of an app request; and request matching verification: when the client initiates a request, the request is made according to the configuration strategy information, a request header carries the interface version information, and the server gateway route carries out verification matching according to the interface header information and then routes to a matched service interface. The new and old compatibility design not only improves the user experience, but also enhances the viscosity of the user, and the upgrading process becomes stable.

Description

Technical Field

[0001] The present invention relates to the field of modern software development and deployment, and in particular to a dynamic version control and service management creation method. Background Art

[0002] In the process of modern software development and deployment, applications (Apps) and services usually need to manage multiple versions to meet the needs of different users, device compatibility, and functional iteration. This multi-version management involves not only the version control of client applications, but also the version control of server APIs. However, as the number of versions increases, how to effectively match and manage these multiple versions of clients and servers has become a complex and challenging problem.

[0003] Traditional version management methods often rely on manual configuration and hard coding. This approach not only increases the workload of development and maintenance, but also easily introduces errors and inconsistencies. For example, when a development team needs to support multiple versions of the client, they must write different code paths for each version and make corresponding adjustments on the server. This is not only time-consuming and labor-intensive, but also prone to omissions and inconsistencies when the version is updated or the function is changed. In addition, the manual management of multi-version matching methods lacks flexibility and is difficult to adapt to rapidly changing business needs and market environments. Therefore, there is an urgent need for an automated and intelligent multi-version matching mechanism to improve development efficiency, reduce human errors, and enhance the scalability and stability of the system.

[0004] Existing technical solutions:

[0005] 2.1 Hard-coded mandatory upgrade interface compatibility strategy

[0006] This technical solution mainly adopts a series of relatively strong and simple measures. For example, through hard-coded interface calls or paths, it ensures that when the application upgrades new functions, users are required to upgrade the application to complete the matching of the service interface. In addition, during the development of new interfaces, it also continues to be compatible with the original application strategy.

[0007] When new features of an application need to be upgraded, developers will match the new service interface with the existing application. To ensure compatibility and stability, developers may use hard-coding to directly specify the specific path or parameters of the interface call. In this way, when users update the application, they must follow the developer's requirements, otherwise they may not be able to use the new features normally.

[0008] In the process of developing new interfaces, developers will also take a series of measures to ensure compatibility between old and new applications. For example, they may retain support for old interfaces in the new interface, or establish a mapping relationship between the new and old interfaces to achieve a smooth transition without affecting the user experience.

[0009] Through hard-coded interface calls, paths, and strategies for continued compatibility with existing applications, the application is guaranteed to run stably when upgrading new functions. Although this approach may limit the user's autonomy to a certain extent, overall, it helps to improve the reliability and maintainability of the application.

[0010] Disadvantages of hard-coded mandatory upgrade interface compatibility strategy

[0011] The strategy of forcing users to upgrade their apps to match new service interfaces may have a negative impact on the user experience, because not all users are willing or able to upgrade immediately, which may cause them to be unable to use the latest features or services, resulting in frustration and dissatisfaction. At the same time, frequently requiring users to upgrade their apps will also increase the user's update costs, including time, data traffic, and possible compatibility issues. These costs may be too high, causing some users to choose to give up using the app. In addition, although the strategy of continuous compatibility with existing apps helps reduce version fragmentation, the cost of maintaining old versions will increase over time, which not only increases the burden on the development team, but may also lead to resource dispersion and affect the development speed of new features.

[0012] Hard-coded interface calls or paths may become a potential source of security vulnerabilities. If attackers can predict or discover these hard-coded values, they may exploit this to launch attacks. The use of hard-coded interface calls or paths limits the flexibility of the system. When the interface or path needs to be changed, the entire application must be recompiled and deployed, which is not conducive to rapid iteration and response to market changes. As application versions continue to accumulate, it will become increasingly difficult to maintain multiple versions of applications and services. Each version needs to be tested and maintained separately, which not only increases the workload but also increases the risk of errors. Long-term reliance on simple measures such as hard coding and forced upgrades will lead to the accumulation of technical debt, which may require more time and resources to repay in the future, affecting the long-term health and sustainable development of the project. Therefore, developers should seek more flexible, user-friendly and sustainable version management and service interface matching strategies. Summary of the invention

[0013] In view of the above problems, the present invention is proposed to provide a dynamic version control and service management creation method that overcomes the above problems or at least partially solves the above problems.

[0014] According to one aspect of the present invention, a dynamic version control and service management creation method is provided, the creation method comprising:

[0015] Configuration delivery update: When the application starts, it first requests the server function configuration interface. When the server receives the request, it returns the full amount of configuration policy information. When the app requests different function interfaces, it makes requests based on the configuration policy information.

[0016] Request matching verification: When the client initiates a request, it makes a request based on the configured policy information. The request header carries the interface version information. The server gateway routing verifies and matches based on the interface header information, and then routes to the matching service interface.

[0017] Optionally, the policy information includes the ID and address of each request interface and information on the validity period.

[0018] Optionally, the configuration update specifically includes:

[0019] When the application starts, it first sends a request to the server to obtain data from the function configuration interface;

[0020] After receiving this request, the server processes the request and provides a response;

[0021] When the APP needs to request a certain functional interface, it constructs a request based on the configuration policy information obtained from the server;

[0022] This includes using the correct interface ID and address, and ensuring that the request is sent within a valid time frame;

[0023] The APP makes requests based on the configuration policy information, ensuring normal communication with the server;

[0024] The mechanism enables the app to dynamically adapt to changes on the server side;

[0025] If the server interface changes, or the validity period of some interfaces has expired, the APP obtains the latest configuration policy information by re-requesting the function configuration interface to ensure normal operation.

[0026] Optionally, the processing the request and providing the response specifically includes:

[0027] The response contains the full amount of configuration policy information, including the ID and address of each request interface, and key data of the validity period;

[0028] The policy information will guide the APP on how to operate when multiple functional interfaces are requested.

[0029] Optionally, the request matching verification specifically includes:

[0030] When the client initiates a request, it makes the request based on the configured information;

[0031] When the client needs to send a request to the server, it first builds the request according to the pre-defined configuration information. During the process of building the request, the client adds the interface version information in the request header;

[0032] When the request reaches the server, the server gateway will receive the request and check the interface version information in the request header;

[0033] The server gateway determines the interface version and routes the request to the service interface that matches the version.

[0034] Optionally, making a request based on the configured information specifically includes: the request header will carry interface version information, and the server gateway routing will perform verification and matching based on the interface version information in the request header.

[0035] The predefined configuration information specifically includes: the address of the target server, the port number and the specific path of the request.

[0036] Optionally, the interface version information includes a version number.

[0037] The present invention provides a dynamic version control and service management creation method, the creation method includes: configuration delivery update, when the application is started, first request the server function configuration interface, when the server receives the request, return the full amount of configuration policy information, and make requests according to the configuration policy information when different function interfaces of the app are requested; request matching verification, when the client initiates a request, make a request according to the configuration policy information, the request header carries the interface version information, the server gateway routing verifies and matches according to the interface header information, and then routes to the matching service interface. The design of new and old compatibility not only improves the user experience, but also enhances the user stickiness, and the upgrade process becomes smooth.

[0038] The above description is only an overview of the technical solution of the present invention. In order to more clearly understand the technical means of the present invention, it can be implemented according to the contents of the specification. In order to make the above and other purposes, features and advantages of the present invention more obvious and easy to understand, the specific implementation methods of the present invention are listed below. BRIEF DESCRIPTION OF THE DRAWINGS

[0039] In order to more clearly illustrate the technical solutions of the embodiments of the present invention, the accompanying drawings required for use in the description of the embodiments will be briefly introduced below. Obviously, the accompanying drawings described below are only some embodiments of the present invention. For ordinary technicians in this field, other accompanying drawings can be obtained based on these accompanying drawings without paying creative work.

[0040] Figure 1 A flowchart of configuration update provided by an embodiment of the present invention;

[0041] Figure 2 A flowchart of request matching verification provided by an embodiment of the present invention. DETAILED DESCRIPTION

[0042] The exemplary embodiments of the present disclosure will be described in more detail below with reference to the accompanying drawings. Although the exemplary embodiments of the present disclosure are shown in the accompanying drawings, it should be understood that the present disclosure can be implemented in various forms and should not be limited by the embodiments set forth herein. On the contrary, these embodiments are provided to enable a more thorough understanding of the present disclosure and to fully convey the scope of the present disclosure to those skilled in the art.

[0043] The terms "comprises" and "having" and any variations thereof in the description embodiments, claims and drawings of the present invention are intended to cover non-exclusive inclusions, for example, including a series of steps or units.

[0044] The technical solution of the present invention is further described in detail below in conjunction with the accompanying drawings and embodiments.

[0045] A dynamic version control and service management creation method, comprising:

[0046] Configuration delivery update: When the application (APP) is started, it first requests the server function configuration interface. When the server receives the request, it returns the full amount of configuration policy information, including the ID and address of each request interface, the effective time and other information. This information is requested based on the configuration policy information when different function interfaces of the app are requested.

[0047] Request matching verification: When the client initiates a request, it makes a request based on the configured information. The request header carries the interface version information. The server gateway routing verifies and matches based on the interface header information, and then routes to the matching service interface.

[0048] like Figure 1 As shown, the configuration is updated, including:

[0049] When an application (APP) is started, it first sends a request to the server to obtain data from the function configuration interface. The purpose of this request is to let the APP know how to interact with the server in the future.

[0050] After receiving this request, the server will process it and provide a response. This response contains the full amount of configuration policy information, including the ID and address of each request interface, as well as key data such as validity period. This information will guide the APP on how to operate when different functional interfaces are requested.

[0051] When the APP needs to request a certain functional interface, it constructs the request based on the configuration policy information previously obtained from the server. This includes using the correct interface ID and address, and ensuring that the request is sent within a valid time range. In this way, the APP can make requests based on the configuration policy information, thereby ensuring normal communication with the server.

[0052] This mechanism enables the APP to dynamically adapt to changes on the server side. If the server side interface changes, or the validity period of some interfaces has expired, the APP obtains the latest configuration policy information by re-requesting the function configuration interface to ensure its normal operation. At the same time, this mechanism also improves the flexibility and scalability of the APP, enabling it to better adapt to different application scenarios and needs.

[0053] like Figure 2 As shown, request matching verification, including:

[0054] When the client initiates a request, it makes the request based on the configured information. The request header will carry the interface version information, and the server gateway routing will verify and match the interface version information in the request header to ensure that the request is routed to the correct service interface.

[0055] When the client needs to send a request to the server, it first builds the request based on the predefined configuration information. This configuration information usually includes the address of the target server, the port number, and the specific path of the request. In the process of building the request, the client will add the interface version information in the request header. This version information includes information such as the version number.

[0056] When the request reaches the server, the server gateway receives the request and checks the interface version information in the request header. By verifying this version information, the server gateway can determine which version of the interface the client is requesting.

[0057] Once the server gateway determines the interface version, it will route the request to the service interface that matches the version. Different interface versions can be handled by different service implementations, thus implementing interface version management and control. At the same time, this also ensures that even if there are multiple versions of the interface, the client can find the corresponding service interface through the correct version information.

[0058] The interface version information verification and matching mechanism based on the request header not only improves the flexibility and scalability of the system, but also enables the server to better manage different versions of interfaces and provide more stable and reliable services to the client.

[0059] Beneficial effects:

[0060] 1. Compatibility between old and new

[0061] This ensures that both new applications and old applications with a certain history are perfectly compatible. This new and old compatibility design not only improves the user experience, but also enhances user stickiness.

[0062] 2. Smooth application transition and upgrade

[0063] This makes the application upgrade process very smooth, avoiding the inconvenience and trouble caused by forcing users to upgrade. Many users will feel confused and uncomfortable when faced with sudden application updates, but this solution provides users with a buffer period to gradually adapt to the new version. It not only takes into account the user's feelings, but also reduces the resistance caused by sudden changes.

[0064] The above specific implementation methods further illustrate the objectives, technical solutions and beneficial effects of the present invention in detail. It should be understood that the above are only specific implementation methods of the present invention and are not intended to limit the scope of protection of the present invention. Any modifications, equivalent substitutions, improvements, etc. made within the spirit and principles of the present invention should be included in the scope of protection of the present invention.

Claims

1. A method for creating dynamic version control and service management, characterized in that: The creation method comprises: Configuration is updated. When the application starts, it first requests the server function configuration interface. When the server receives the request, it returns the full configuration policy information. When the app requests different function interfaces, it makes requests based on the configuration policy information. Request matching verification: When the client initiates a request, it makes a request based on the configured policy information. The request header carries the interface version information. The server gateway routing verifies and matches based on the interface header information, and then routes to the matching service interface.

2. A dynamic version control and service management creation method according to claim 1, characterized in that: The policy information includes the ID and address of each request interface and the information of the validity period.

3. A dynamic version control and service management creation method according to claim 1, characterized in that: The configuration delivery update specifically includes: When the application starts, it first sends a request to the server to obtain data from the function configuration interface; After receiving this request, the server processes the request and provides a response; When the APP needs to request a certain functional interface, it constructs a request based on the configuration policy information obtained from the server; This includes using the correct interface ID and address, and ensuring that the request is sent within a valid time frame; The APP makes requests based on the configuration policy information, ensuring normal communication with the server; The mechanism enables the app to dynamically adapt to changes on the server side; If the server interface changes, or the validity period of some interfaces has expired, the APP obtains the latest configuration policy information by re-requesting the function configuration interface to ensure normal operation.

4. A method for creating dynamic version control and service management according to claim 3, characterized in that: The processing of the request and providing the response specifically includes: The response contains the full amount of configuration policy information, including the ID and address of each request interface, and key data of the validity period; The policy information will guide the APP on how to operate when multiple functional interfaces are requested.

5. A method for creating dynamic version control and service management according to claim 1, characterized in that: The request matching verification specifically includes: When the client initiates a request, it makes the request based on the configured information; When the client needs to send a request to the server, it first builds the request according to the pre-defined configuration information. During the process of building the request, the client adds the interface version information in the request header; When the request reaches the server, the server gateway will receive the request and check the interface version information in the request header; The server gateway determines the interface version and routes the request to the service interface that matches the version.

6. A method for creating dynamic version control and service management according to claim 5, characterized in that: The requesting according to the configured information specifically includes: the request header will carry the interface version information, and the server gateway routing will perform verification and matching according to the interface version information in the request header. The predefined configuration information specifically includes: the address of the target server, the port number and the specific path of the request.

7. A method for creating dynamic version control and service management according to claim 5, characterized in that: The interface version information includes a version number.

Images