Surging how to test the business module with the Swagger component

1 , preface

The concept of micro-service architecture has been put forward for a long time, but in recent years has begun to occur frequently, we have started to upgrade into a micro-service architecture, using a variety of technologies, we believe that the framework of service governance is micro-services, the implementation of a single protocol service invocation, micro-services, although not too clearly defined, But I think the service should be a relatively small and separate set of functional units, can be split freely, the CRUD for the business module can be registered as a service, and each service is highly autonomous, from development, deployment is independent, and each service only do a single function, Using domain-driven design to better split into smaller granular modules, and the framework itself provides a variety of protocols, such as WS,TCP,HTTP,MQTT,RTP,RTCP, and has a variety of functions of the middleware, the development of business modules, through the framework can be applied to a variety of business scenarios, Let developers focus on business development This is the real micro-service.

Above just talk about the micro-services, to avoid some people go astray. This article mainly introduces the next surging how to test the business module using the Swagger component

Surging source Download

2. How to use Swagger

Surging integrates the Kestrel component and extends the swagger component, as described below how to use the Swagger component

XML document File Settings

For swagger to generate schema, the XML document file that needs to load the interface module can be set through the project-Properties-Generate-xml document file, as shown in

With the above settings, if the scan loads the business module, you can use the dotnet publish-c release to generate the module file as shown in

File configuration

With swagger, if you use the official surging engine, you need to turn on the Kestrel component, as shown in the following configuration

  "surging": {    "Ip":"${surging_server_ip}|127.0.0.1",    "Watchinterval": -,    "Port":"${surging_server_port}|98",    "MAPPINGIP":"${mapping_ip}",    "Mappingport":"${mapping_port}",    "Token":"true",    "maxconcurrentrequests": -,    "Executiontimeoutinmilliseconds":30000,    "Protocol":"${protocol}| None",//Http, TCP, None    "RootPath":"${rootpath}| D:\\userapp",    "Ports": {      "Httpport":"${httpport}|280",      "Wsport":"${wsport}|96"    },    "requestcacheenabled":false,    "Packages": [      {        "TypeName":"Enginepartmodule",        "Using":"${useengineparts}| Dotnettymodule; Nlogmodule; Messagepackmodule; Consulmodule; Kestrelhttpmodule; Wsprotocolmodule; Eventbusrabbitmqmodule; Cachingmodule;"      }    ]  }

The following is the configuration swagger, which can be disabled if the following configuration is not added swagger

  "Swagger": {    "Version": "${swaggerversion}| V1 ",//" 127.0.0.1:8500 ",    " Title ":" ${swaggertitle}| Surging demo ",    " Description ":" ${swaggerdes}|surging demo ",    " contact ": {      " Name ":" API support ",      " Url ":" Https://github.com/dotnetcore/surging ",      " email ":" [email protected] "    },    " License ": {      " Name ": "MIT",      "Url": "Https://github.com/dotnetcore/surging/blob/master/LICENSE"    }  }

With the above settings, you can access it through Http://127.0.0.1:280/swagger, as shown in

Test upload file

Test download file

Post Test

GET Test

v. Summary

Through the Swagger engine components can generate business interface documentation, better and team collaboration, and the surging plan is to go to the gateway, the "stage" engine components will be expanded to replace the gateway, but also expand the communication protocols, but also welcome the expansion of engine components, Make the ecology more powerful.

Surging how to test the business module with the Swagger component