Gateway-based RESTful and MCP protocol bidirectional conversion system and method

Abstract

This application provides a gateway-based bidirectional conversion system and method for RESTful and MCP protocols. By implementing intelligent protocol conversion at the enterprise-level gateway level, it enables existing RESTful services to quickly acquire the ability to support advanced AI interactions. With the advantages of low cost and standardization, it achieves bidirectional transparent conversion between traditional RESTful services and AI interaction protocols, solving the technical challenge of seamless and low-cost access to AI capabilities for traditional web applications.

Description

Technical Field

[0001] This application relates to the field of network technology, specifically to a gateway-based bidirectional conversion system and method for RESTful and MCP protocols. Background Technology

[0002] Currently, many core business systems of enterprises, such as Enterprise Resource Planning (ERP), Customer Relationship Management (CRM), and Human Resource Management (HRM), are developed based on the traditional Model-View-Controller (MVC) architecture and provide API interfaces in the style of Representational State Transfer (RESTful) to the outside world.

[0003] With the popularization of artificial intelligence (AI) technology, it has become an urgent need to inject intelligent capabilities into the core business systems of these enterprises.

[0004] However, directly enabling AI agents to call traditional RESTful interfaces faces the following technical bottlenecks: 1. Protocol mismatch. The RESTful protocol is based on a simple request-response pattern and resource representation, and lacks support for AI-native interaction patterns such as multi-turn dialogues, complex contexts, and tool calls. Emerging AI interaction protocols, such as model context protocols, are designed for these types of scenarios. 2. High transformation costs. To directly support the MCP protocol in the existing system, a deep reconstruction of each service interface is required, which is labor-intensive, risky, and could compromise the stability of the existing system. 3. Lack of a standardized access layer. Different AI model services provide different APIs, which requires the application layer to write a lot of adaptation code, resulting in high integration complexity and difficulty in maintenance. Summary of the Invention

[0005] This application provides a gateway-based bidirectional conversion system and method for RESTful and MCP protocols. By implementing intelligent protocol conversion at the enterprise-level gateway level, it enables existing RESTful services to quickly acquire the ability to support advanced AI interactions. With the advantages of low cost and standardization, it achieves bidirectional transparent conversion between traditional RESTful services and AI interaction protocols, solving the technical challenge of seamless and low-cost access to AI capabilities for traditional web applications.

[0006] In the first aspect, this application provides a gateway-based bidirectional conversion system between RESTful and MCP protocols, the system including a protocol adaptation gateway and a Spring AI integration middleware; The protocol adaptation gateway identifies the protocol type of the first processing request by the protocol recognizer. Based on the protocol type identification result, it combines a middleware chain using the chain of responsibility pattern with a bidirectional conversion engine between RESTful and MCP protocols to convert the first processing request into a protocol and transmits the converted second processing request in MCP protocol form to the Spring AI integration middleware. With the corresponding AI model pre-registered and an adapter class written using the ChatClient unified interface, the Spring AI integration middleware, combined with a context-aware mechanism that automatically injects dialogue history context before and after model invocation, calls the AI ​​model to process the second processing request, obtains the corresponding first processing result, and then returns the converted second processing result in RESTful protocol form to the requester of the first processing request through the protocol adaptation gateway.

[0007] Secondly, this application provides a gateway-based bidirectional conversion method for RESTful and MCP protocols. The method is applied to a gateway-based bidirectional conversion system for RESTful and MCP protocols. The system includes a protocol adaptation gateway and a Spring AI integration middleware. The method includes: The protocol adaptation gateway obtains the first processing request; The protocol adaptation gateway identifies the protocol type of the first processing request by the protocol recognizer. Based on the protocol type identification result, it combines a middleware chain using the chain of responsibility pattern with a bidirectional conversion engine between RESTful and MCP protocols to convert the first processing request into a protocol and transmits the converted second processing request in MCP protocol form to the Spring AI integration middleware. With the corresponding AI model pre-registered and the adapter class written using the ChatClient unified interface, the Spring AI integration middleware, combined with the context-aware mechanism that automatically injects the dialogue history context before and after model invocation, calls the AI ​​model to process the second processing request and obtains the corresponding first processing result. The protocol adaptation gateway returns the converted second processing result in RESTful protocol form to the requester of the first request that needs to be processed.

[0008] Thirdly, this application provides a computer-readable storage medium storing a plurality of instructions adapted for loading by a processor to execute the method provided in the second aspect of this application.

[0009] From the above, it can be concluded that this application has the following beneficial effects: To address the goal of bidirectional conversion between RESTful and MCP protocols, this application implements intelligent protocol conversion at the enterprise-level gateway level, enabling existing RESTful services to quickly acquire the ability to support advanced AI interactions. With the advantages of low cost and standardization, it achieves bidirectional transparent conversion between traditional RESTful services and AI interaction protocols, solving the technical challenge of seamless and low-cost access to AI capabilities for traditional web applications. Attached Figure Description

[0010] To more clearly illustrate the technical solutions in the embodiments of this application, the accompanying drawings used in the description of the embodiments will be briefly introduced below. Obviously, the accompanying drawings described below are only some embodiments of this application. For those skilled in the art, other drawings can be obtained based on these drawings without creative effort.

[0011] Figure 1 A schematic diagram of the overall system architecture for applying for a gateway-based bidirectional conversion system between RESTful and MCP protocols; Figure 2 A logical view adapted to the gateway's internal processing for the purposes of this application protocol; Figure 3 This is a logical diagram illustrating the data mapping and transformation in this application; Figure 4 This is a logical diagram illustrating the grayscale release and rollback control in this application. Figure 5 This is a flowchart illustrating a gateway-based bidirectional conversion method for RESTful and MCP protocols in this application. Detailed Implementation

[0012] The technical solutions of the embodiments of this application will be clearly and completely described below with reference to the accompanying drawings. Obviously, the described embodiments are only some embodiments of this application, and not all embodiments. Based on the embodiments of this application, all other embodiments obtained by those skilled in the art without creative effort are within the scope of protection of this application.

[0013] The terms "first," "second," etc., used in the specification, claims, and accompanying drawings of this application are used to distinguish similar objects and are not necessarily used to describe a specific order or sequence. It should be understood that such data can be interchanged where appropriate so that the embodiments described herein can be implemented in a sequence other than that illustrated or described herein. Furthermore, the terms "comprising" and "having," and any variations thereof, are intended to cover non-exclusive inclusion; for example, a process, method, system, product, or device that includes a series of steps or modules is not necessarily limited to those explicitly listed, but may include other steps or modules not explicitly listed or inherent to such processes, methods, products, or devices. The naming or numbering of steps appearing in this application does not imply that the steps in the method flow must be performed in the chronological / logical order indicated by the naming or numbering. The execution order of named or numbered process steps can be changed according to the desired technical purpose, as long as the same or similar technical effect is achieved.

[0014] The module division described in this application is a logical division. In practical applications, there may be other division methods. For example, multiple modules may be combined or integrated into another system, or some features may be ignored or not executed. Furthermore, the shown or discussed mutual coupling, direct coupling, or communication connections may be through interfaces, and the indirect coupling or communication connections between modules may be electrical or other similar forms, none of which are limited in this application. Moreover, the modules or sub-modules described as separate components may or may not be physically separated, may or may not be physical modules, or may be distributed across multiple circuit modules. Some or all of the modules can be selected according to actual needs to achieve the purpose of the solution in this application.

[0015] To address the goal of bidirectional conversion between RESTful and MCP protocols, this application presents a gateway-based bidirectional conversion system for RESTful and MCP protocols. This system comprises two main components: a protocol adaptation gateway and a Spring AI integration middleware. Based on these two components, this application achieves intelligent protocol conversion at the enterprise-level gateway level, enabling existing RESTful services to quickly support advanced AI interactions. With the advantages of low cost and standardization, it achieves bidirectional transparent conversion between traditional RESTful services and AI interaction protocols, solving the technical challenge of seamless and low-cost access to AI capabilities for traditional web applications.

[0016] Specifically, in combination Figure 1 The diagram shown represents an overall system architecture of the gateway-based bidirectional conversion system for RESTful and MCP protocols in this application. The configurations and collaborative operations of the two main system components can be summarized as follows: 1) Protocol adaptation gateway The protocol adaptation gateway identifies the protocol type of the first processing request using a protocol recognizer. Based on the protocol type identification result, it combines a middleware chain using the chain of responsibility pattern with a bidirectional conversion engine for RESTful and MCP protocols to convert the first processing request into a protocol. The converted second processing request, in MCP protocol form, is then transmitted to the Spring AI integration middleware.

[0017] For enterprises, the application of AI models typically involves initiating a processing request from the client side to trigger the system to call the AI ​​model to handle specific data processing tasks. It is easy to see that this processing request is a RESTful protocol request, so the processing request can also be called a RESTful request.

[0018] At the same time, it is easy to understand that, in order to facilitate the distinction between processing requests at different stages, the initial processing request obtained here is recorded as the first processing request, and the processing request after protocol conversion is recorded as the second processing request. The same applies to subsequent processing results involving protocol conversion.

[0019] In terms of processing, the protocol adaptation gateway can be configured with a protocol identifier, a middleware processing chain, and a routing forwarder, which corresponds to the case where the protocol adaptation gateway consists of a protocol access layer, a middleware processing engine, and a routing forwarding layer.

[0020] For the first processing request initiated by the client, if the protocol identifier identifies it as a normal request, that is, involving HTTP requests and HTP responses in the form of RESTful protocol, then for the RESTful API of traditional web applications, there is no need to involve AI interaction or bidirectional conversion between RESTful and MCP protocols, and the application service can work normally.

[0021] If the protocol identifier's processing result involves an AI interaction request, it can be converted into the MCP protocol form to obtain a second processing request, namely the MCP request. In this way, the routing forwarder can transmit the MCP request to the corresponding AI model.

[0022] In terms of specific implementation, the protocol adapter gateway can be built on a high-performance asynchronous framework such as Netty or Reactor, and supports high-concurrency requests.

[0023] Among them, the Netty framework, due to its asynchronous non-blocking I / O model, has the advantages of low performance loss and high concurrency capability. In addition, it also has advantages such as high performance, low latency, unified API, multi-protocol support, and excellent scalability. The Reactor framework, due to its event-driven pattern, is suitable for high-concurrency scenarios and also has advantages such as modularity and decoupling, high flexibility, and good customizability. Thus, it can lay a good application foundation for the protocol adaptation gateway of this application.

[0024] Furthermore, for the request protocol identification step, the middleware chain involved, as mentioned above, can specifically adopt the chain of responsibility pattern. Each middleware (such as AuthMiddleware, LoggingMiddleware, and ConversionMiddleware) independently handles specific logic, passes data through context objects, and supports flexible plugging and unplugging and sorting.

[0025] In terms of detailed operation, the protocol adaptation gateway can determine whether the first processing request itself is in the form of a RESTful protocol by parsing the Content-Type header and request body characteristics of the first processing request, and whether the first processing request involves the MCP protocol form corresponding to AI interaction, thereby completing the millisecond-level protocol judgment.

[0026] The extracted Content-Type headers, such as application / json and application / x-mcp, are used to determine whether the first processing request itself is in the form of a RESTful protocol, while the extracted request body features are used to determine whether the first processing request involves the MCP protocol form corresponding to AI interaction.

[0027] If both are true, then it is obvious that a bidirectional conversion engine for RESTful and MCP protocols needs to be called to perform protocol conversion processing from RESTful requests to MCP requests.

[0028] This RESTful to MCP protocol bidirectional conversion engine, corresponding to the protocol conversion here and the subsequent processing result protocol conversion, has two built-in rule engines: A REST-to-MCP converter that maps RESTful POST / api / chat request bodies to MCP formats such as {"model":"deepseek-chat","messages":[...]}. The MCP-to-REST converter adapts the complex JSON response in MCP format returned by the AI ​​model to the simplified structure expected by the front end, namely the RESTful format.

[0029] In the specific protocol conversion process, the conversion rule configuration may involve four main aspects: path mapping rules, field mapping table, model configuration, and context template. The field mapping details of the request body parameters of the corresponding RESTful request may involve four main aspects: injected message prefix, body, attachments, and prompt word instructions.

[0030] At this point, it can also be combined with Figure 2 The following is a logical view of the protocol adaptation to the gateway's internal processing shown in this application: Figure 3 The diagram shown is a logical illustration of the data mapping and transformation in this application, for a more intuitive understanding.

[0031] 2) Spring AI Integration Middleware With the corresponding AI model pre-registered and an adapter class written using the ChatClient unified interface, the Spring AI integration middleware, combined with a context-aware mechanism that automatically injects dialogue history context before and after model invocation, calls the AI ​​model to process the second processing request, obtains the corresponding first processing result, and then returns the converted second processing result in RESTful protocol form to the requester of the first processing request through the protocol adaptation gateway.

[0032] The Spring AI integration middleware is responsible for the specific processing directly related to AI interaction. In the specific configuration, the AI ​​model called by this application system can be either a relevant AI model deployed locally within the enterprise or a relevant AI model from outside the enterprise, such as AI model calling services provided by third parties.

[0033] Furthermore, the Spring AI integration middleware and the aforementioned protocol adapter gateway can be deployed on the same network device node involved in the system of this application, or on different network device nodes, which can be flexibly configured according to actual needs.

[0034] For the application of AI models, in the early configuration work, a custom Spring Boot Starter (cp-ai-spring-boot-starter) can be developed. Its auto-configuration class will scan the AI ​​model client dependencies in the classpath and automatically register them as beans in the Spring container. Using the unified interface of Spring AI's ChatClient, adapter classes can be written. Taking the specific AI model DeepSeek as an example, it can involve the AI ​​model client dependency DeepSeek-Client and the adapter class DeepSeekMCPAdapter to realize the conversion of standard MCP requests into DeepSeek API call logic and handle streaming responses.

[0035] At the same time, to improve the performance of AI models, a context-aware mechanism is introduced. Specifically, the Spring AI integration middleware can also achieve a context-aware mechanism that automatically injects dialogue history context before and after model invocation through the AOP aspect Model Invocation Aspect.

[0036] In addition to the AOP (Model Invocation Aspect), other context-aware mechanisms can be used at the detail level, such as working memory-based, multimodal feature fusion, context-aware retrieval augmented generation (RAG), state machine and rule engine combination, and Transformer context window mechanism.

[0037] When at least two context-aware methods are applied, a weighting mechanism can be introduced to combine different context-aware methods. Compared to calling a specific context-aware method for the current applicable scenario, using multiple context-aware methods at the same time helps to integrate different forms of context-aware capabilities and balance the influence of different context-aware methods with dynamic weights, thereby obtaining a more refined context-aware effect that takes into account different context-aware methods and adapts to the current situation.

[0038] As can be seen from the above solution, this application achieves intelligent protocol conversion at the enterprise-level gateway level to enable existing RESTful services to quickly support advanced AI interaction capabilities. With the advantages of low cost and standardization, it realizes transparent bidirectional conversion between traditional RESTful services and AI interaction protocols, solving the technical problem of seamless and low-cost access to AI capabilities for traditional web applications.

[0039] In addition to the detailed optimizations mentioned above, this application can also have corresponding system optimizations in other aspects to further improve system performance and achieve better application results.

[0040] Specifically, the system in this application may also include a security and compliance control module to provide fine-grained access control and data anonymization. This security and compliance control module can be used for: 1. Perform authentication processing on the request; Specifically, it can integrate existing or custom-configured security frameworks such as Spring Security 6.x to provide authentication types such as JSON Web Token (JWT) verification for requests obtained by the gateway itself and the transformed requests.

[0041] 2. Perform real-time desensitization on sensitive fields involved in system processing; Specifically, a Data Masking Filter can be pre-configured to perform real-time desensitization on patterned sensitive fields such as mobile phone numbers and email addresses in request messages after protocol conversion and before log recording. For example, the middle four digits of a mobile phone number are replaced with asterisks (i.e., "*").

[0042] Besides directly replacing sensitive fields with asterisks or other symbols, encryption methods such as hash algorithms and key encryption can also be used to achieve data desensitization.

[0043] 3. Record audit logs for system processing.

[0044] Recording audit logs helps with retrospective analysis and targeted analysis of specific situations.

[0045] In practice, the corresponding audit log component can record key information such as the source IP, target model, request time, and operation result involved in each protocol conversion operation, and can be persistently stored for no less than 180 days.

[0046] In addition, the system of this application may also include a canary release and operation and maintenance module to ensure that the risks of the protocol switching process are controllable. This canary release and operation and maintenance module can be specifically used for: 1. Manage the backend service addresses and traffic weights for different versions; Understandably, this can also be linked or integrated with configuration centers, such as Nacos Configuration Center, to manage the functional services of different system versions, adjust the backend service addresses and traffic weights involved, and better serve the canary release work and the operation and maintenance work.

[0047] 2. Route the request to the new version of the service; Similar to the types mentioned above, the dynamic routing management here also serves the purpose of canary releases and operations. Specifically, a Canary Release Router mechanism can be deployed at the gateway layer to route requests to the new version of the service based on specific markers in the request header (such as X-User-Group:beta) or the global traffic percentage (such as 5%).

[0048] 3. Collect the latency and error rate of the new version interface in real time. When the error rate exceeds 1%, reset the traffic weight to 0 to achieve a fast rollback.

[0049] Rollback is clearly an important part of the implementation of canary release and operation and maintenance work, in order to avoid further impact on the current version of the service.

[0050] Specifically, monitoring systems such as Prometheus can be deployed here to monitor latency and error rates, while traffic weight management can be achieved by using Webhook communication mechanisms to call gateway management APIs.

[0051] For information on canary releases and rollback control, please refer to [link / reference]. Figure 4 The diagram shown is a logical illustration of the grayscale release and rollback control of this application, for a more intuitive understanding.

[0052] Meanwhile, as an example of an application scenario of this application, the system of this application can be specifically applied to the resume analysis scenario of the HR system. In the resume analysis scenario, the corresponding analysis report is obtained based on the job description text using an AI model.

[0053] As mentioned earlier, traditional human resource management (HRM) systems in enterprise online business systems are generally based on the MVC architecture. Therefore, when it is necessary to iterate and introduce AI models to serve resume analysis, there is a lack of solutions to the problem of transparent two-way conversion between traditional RESTful services and AI interaction protocols, which makes it difficult to upgrade traditional applications to intelligence.

[0054] Against this backdrop, in resume analysis scenarios, the integration of this application system allows for seamless and stable access to AI models. Based on the AI ​​model, corresponding analysis reports can be obtained from job description texts, providing excellent data support for HR staff or the system.

[0055] Of course, in addition to resume analysis in the human resources field, this application system can also be used in other types of application scenarios, which can be adapted to actual needs.

[0056] Meanwhile, for the aforementioned protocol adaptation gateway, this application also considers that in addition to providing a second processing request in the form of an adapted MCP for the invocation of AI models, it can also carry additional information references for the second processing request based on the protocol conversion operations involved, including the deep content conversion situation, so that the AI ​​model can perform more refined analysis and processing on the basis of conventional analysis and processing tasks.

[0057] This information reference can be compiled by combining the processing differences between other requests and the current request in the overall protocol conversion operation, or it can be compiled for the current request in a separate / individual protocol conversion operation. Specifically, it may involve reference indicators such as the request initiation time, the request initiation address, the complexity of the original content (indicated by corresponding indicators), the abnormal location of the original content, the specific abnormal content in the original content, the key content in the original content, and the suspicious content in the original content.

[0058] In the context of resume analysis, the reference metrics can also be configured to account for the similarities and differences between different resumes in terms of request initiation behavior and specific resume content. By combining the design concept of configuring adaptability information references with specific application scenarios, the AI ​​model that performs resume analysis can be provided with information references that are highly adapted to the specific application scenario and can promote more refined resume analysis results.

[0059] Furthermore, the AI ​​model involved in this application can specifically be a deep neural network of the large language model in deep learning models. The large language model can handle long-distance dependencies, understand and generate coherent text content, has strong context modeling capabilities, and currently has good application prospects.

[0060] In this context, the AI ​​models in this application may include specific large language model models such as DeepSeek, Wenxin Yiyan, and Tongyi Qianwen.

[0061] Understandably, whether a single type of large language model is configured or different types of large language models are configured, the system can involve the application of multiple AI models at the same time, thereby meeting the needs of high concurrency and flexible use of AI models.

[0062] Taking the resume analysis scenario mentioned above as an example, the following set of application examples can provide a more vivid understanding of the system configuration: Example - Adding AI intelligent analysis capabilities to existing RESTful interfaces Scenario Description: The existing HR system has a POST / api / v1 / job / analysis interface that receives job description text in JSON format and returns an analysis report in a fixed format. Now, it needs to be integrated with the DeepSeek large model to achieve intelligent extraction of job requirements and skill points.

[0063] System Configuration: Deploy the protocol conversion gateway involved in this application and configure its address as a new endpoint for the HR system, such as https: / / gateway.company.com / ai-proxy (this is an example address and not the actual address).

[0064] In the gateway management backend, configure a routing rule to identify requests to the path / ai-proxy / hr / job-analysis as needing to be converted to the MCP protocol and routed to the DeepSeek model service.

[0065] Configure data mapping rules: Map the {"description":"Hiring a Java engineer..."} field in the RESTful request to the messages array in the MCP request: [{"role":"user","content":"Please analyze the following job description:..."}].

[0066] Request processing flow (in combination) Figure 2 ): S1: The HR system frontend sends a POST request to https: / / gateway.company.com / ai-proxy / hr / job-analysis just like calling a regular API.

[0067] S2: The Protocol Identification Middleware of the Protocol Adaptor Gateway recognizes the request as a RESTful protocol and matches the "Job Analysis" routing rule.

[0068] S3: The Rest To MCP Conversion Middleware starts and generates a standard MCP request message according to the configured mapping rules. At the same time, the Security Middleware verifies the caller's API Token.

[0069] S4: The gateway forwards the generated MCP request to the Spring AI integration middleware. The DeepSeek MCPA adapter receives the request and calls the official DeepSeek API.

[0070] S5: DeepSeek returns a JSON result containing a list of skill points. MCP To Rest ConversionMiddleware converts this to the format expected by the HR frontend: {"skills":["Java","SpringCloud","MySQL"],"summary":"..."}.

[0071] S6: Logging Middleware records audit logs (which have been anonymized), and the gateway returns the final response to the HR system frontend.

[0072] Results: The HR system gained advanced AI analytics capabilities without modifying any backend business code. Operations personnel can also monitor the API call activity and AI service stability through a monitoring panel, and control the rollout of new features through a phased rollout strategy.

[0073] Finally, the above solutions have the following specific advantages in general: 1. Seamless integration: It enables a smooth upgrade of traditional RESTful applications to AI capabilities with "zero code" or "low code" without the need for business logic refactoring, protecting existing investments and allowing for easy integration into existing application scenarios.

[0074] 2. High-performance conversion: Through asynchronous gateways and efficient memory data mapping, protocol conversion latency can be controlled within 50ms, meeting enterprise-level real-time interaction requirements and demonstrating significant practical application value.

[0075] 3. Standardization and scalability: It provides a unified standard for accessing AI capabilities, and through its plug-in design, it can be easily extended to support new AI models or interaction protocols, greatly improving the system's future adaptability.

[0076] 4. Enterprise-level protection: Built-in end-to-end security control, compliance auditing, and canary release capabilities ensure the reliability and risk controllability of the system in sensitive scenarios such as finance and government affairs.

[0077] The above is an introduction to the gateway-based bidirectional conversion system of RESTful and MCP protocols in this application. Correspondingly, this application also provides a gateway-based bidirectional conversion method of RESTful and MCP protocols from the perspective of system processing flow. This method is obviously applicable to the gateway-based bidirectional conversion system of RESTful and MCP protocols. The system may include a protocol adaptation gateway and Spring AI integration middleware.

[0078] Based on this brief system configuration requirement, refer to Figure 5 The diagram shown illustrates a flowchart of a gateway-based bidirectional conversion method for RESTful and MCP protocols according to this application. This gateway-based bidirectional conversion method for RESTful and MCP protocols may include the following steps S501 to S504: Step S501: The protocol adaptation gateway obtains the first processing request; In step S502, the protocol adaptation gateway identifies the protocol type of the first processing request by the protocol recognizer. Based on the protocol type identification result, it combines the middleware chain using the chain of responsibility pattern with the bidirectional conversion engine between RESTful and MCP protocols to convert the first processing request into a protocol and transmits the converted second processing request in MCP protocol form to the Spring AI integration middleware. In step S503, the Spring AI integration middleware, having pre-registered the corresponding AI model and written an adapter class using the ChatClient unified interface, combines the context-aware mechanism of automatically injecting dialogue history context before and after model invocation, calls the AI ​​model to process the second processing request, and obtains the corresponding first processing result. Step S504: The protocol adaptation gateway returns the converted second processing result in RESTful protocol form to the requester of the first request that needs to be processed.

[0079] In one exemplary embodiment, the protocol adapter gateway is built on a high-performance asynchronous framework based on Netty or Reactor and supports high-concurrency requests.

[0080] In another exemplary embodiment, the protocol adaptation gateway determines whether the first processing request itself is in the form of a RESTful protocol and whether the first processing request involves the MCP protocol form corresponding to AI interaction by parsing the Content-Type header and request body characteristics of the first processing request.

[0081] In yet another exemplary embodiment, the Spring AI integration middleware uses the AOP aspect ModelInvocation Aspect to implement a context-aware mechanism that automatically injects dialogue history context before and after model invocation.

[0082] In yet another exemplary embodiment, the system further includes a security and compliance control module, which is used to: Perform authentication processing on the request; Real-time desensitization of sensitive fields involved in system processing; Record audit logs for system processing.

[0083] In yet another exemplary embodiment, the system further includes a canary release and operation module, which is used for: Manage the backend service addresses and traffic weights for different versions; The request will be routed to the new version of the service. Real-time monitoring of latency and error rate of the new version interface; when the error rate exceeds 1%, the traffic weight is reset to 0 to achieve rapid rollback.

[0084] In another exemplary embodiment, the system is specifically applied to the resume analysis scenario of an HR system, in which an AI model is used to obtain a corresponding analysis report based on the job description text.

[0085] In yet another exemplary embodiment, the AI ​​model specifically includes DeepSeek, Wenxin Yiyan, and Tongyi Qianwen.

[0086] Those skilled in the art will clearly understand that, for the sake of convenience and brevity, the specific working process of the gateway-based bidirectional conversion method for RESTful and MCP protocols described above can be found in [reference needed]. Figure 1 The description of the gateway-based bidirectional conversion system for RESTful and MCP protocols in the corresponding embodiment will not be repeated here.

[0087] Those skilled in the art will understand that all or part of the steps in the various methods of the above embodiments can be performed by instructions, or by instructions controlling related hardware. These instructions can be stored in a computer-readable storage medium and loaded and executed by a processor.

[0088] Therefore, this application provides a computer-readable storage medium storing a plurality of instructions that can be loaded by a processor to execute the present application. Figure 5 For details on the steps of the gateway-based bidirectional conversion method for RESTful and MCP protocols in the corresponding embodiment, please refer to the following: Figure 5 The description of the gateway-based bidirectional conversion method for RESTful and MCP protocols in the corresponding embodiment will not be repeated here.

[0089] The computer-readable storage medium may include: read-only memory (ROM), random access memory (RAM), disk or optical disk, etc.

[0090] Because of the instructions stored in the computer-readable storage medium, the present application can be executed as described above. Figure 5 The steps of the gateway-based bidirectional conversion method for RESTful and MCP protocols in the corresponding embodiment can therefore achieve the results of this application. Figure 5 The beneficial effects of the gateway-based bidirectional conversion method for RESTful and MCP protocols in the corresponding embodiment are detailed in the preceding description and will not be repeated here.

[0091] The foregoing has provided a detailed description of the gateway-based bidirectional conversion system and method for RESTful and MCP protocols, as well as the computer-readable storage medium provided in this application. Specific examples have been used to illustrate the principles and implementation methods of this application. The descriptions of the embodiments above are only for the purpose of helping to understand the core ideas of this application; furthermore, those skilled in the art will recognize that, based on the ideas of this application, there will be changes in the specific implementation methods and application scope. Therefore, the content of this specification should not be construed as a limitation of this application.

Claims

1. A gateway-based RESTful and MCP protocol bidirectional conversion system, characterized in that, The system includes a protocol adaptation gateway and a Spring AI integration middleware; The protocol adaptation gateway identifies the protocol type of the first processing request by a protocol recognizer. Based on the protocol type identification result, it combines a middleware chain using the chain of responsibility pattern with a bidirectional conversion engine for RESTful and MCP protocols to convert the first processing request into a protocol and transmits the converted second processing request in MCP protocol form to the Spring AI integration middleware. The Spring AI integration middleware, after pre-registering the corresponding AI model and writing an adapter class using the ChatClient unified interface, combines a context-aware mechanism that automatically injects dialogue history context before and after model invocation, calls the AI ​​model to process the second processing request, obtains the corresponding first processing result, and then returns the converted second processing result in RESTful protocol form to the requester of the first required processing request through the protocol adaptation gateway.

2. The system of claim 1, wherein, The protocol adapter gateway is built on a high-performance asynchronous framework such as Netty or Reactor and supports high-concurrency requests.

3. The system of claim 1, wherein, The protocol adaptation gateway determines whether the first processing request itself is in the form of the RESTful protocol and whether the first processing request involves the MCP protocol form corresponding to AI interaction by parsing the Content-Type header and request body characteristics of the first processing request.

4. The system according to claim 1, characterized in that, The Spring AI integration middleware, through the AOP (Model Invocation Aspect), implements a context-aware mechanism that automatically injects the dialogue history context before and after model invocation.

5. The system according to claim 1, characterized in that, The system also includes a security and compliance control module, which is used for: Perform authentication processing on the request; Real-time desensitization of sensitive fields involved in system processing; The system processes are logged.

6. The system according to claim 1, characterized in that, The system also includes a canary release and operation and maintenance module, which is used for: Manage the backend service addresses and traffic weights for different versions; The request will be routed to the new version of the service. The latency and error rate of the new version interface are collected in real time. When the error rate exceeds 1%, the traffic weight is reset to 0 to achieve a fast rollback.

7. The system according to claim 1, characterized in that, The system is specifically applied to the resume analysis scenario in the HR system. In the resume analysis scenario, the AI ​​model is used to obtain the corresponding analysis report based on the job description text.

8. The system according to claim 1, characterized in that, The AI ​​models specifically include DeepSeek, Wenxin Yiyan, and Tongyi Qianwen.

9. A gateway-based bidirectional conversion method for RESTful and MCP protocols, characterized in that, The method is applied to a gateway-based bidirectional conversion system between RESTful and MCP protocols. The system includes a protocol adaptation gateway and a Spring AI integration middleware. The method includes: The protocol adaptation gateway obtains the first processing request; The protocol adaptation gateway identifies the protocol type of the first processing request by a protocol recognizer. Based on the protocol type identification result, it combines a middleware chain using the chain of responsibility pattern with a bidirectional conversion engine for RESTful and MCP protocols to convert the first processing request into a protocol and transmits the converted second processing request in MCP protocol form to the Spring AI integration middleware. The Spring AI integration middleware, having pre-registered the corresponding AI model and written an adapter class using the ChatClient unified interface, combines a context-aware mechanism that automatically injects dialogue history context before and after model invocation, calls the AI ​​model to process the second processing request, and obtains the corresponding first processing result. The protocol adaptation gateway returns a second processing result in RESTful protocol form to the requester of the first request that needs to be processed.

10. A computer-readable storage medium, characterized in that, The computer-readable storage medium stores a plurality of instructions adapted for loading by a processor to execute the method of claim 9.

Images