SwaggerConfig.cs 17 KB

123456789101112131415161718192021222324252627282930313233343536373839404142434445464748495051525354555657585960616263646566676869707172737475767778798081828384858687888990919293949596979899100101102103104105106107108109110111112113114115116117118119120121122123124125126127128129130131132133134135136137138139140141142143144145146147148149150151152153154155156157158159160161162163164165166167168169170171172173174175176177178179180181182183184185186187188189190191192193194195196197198199200201202203204205206207208209210211212213214215216217218219220221222223224225226227228229230231232233234235236237238239240241242243244245246247248249250251252253254255256257258259260261262263
  1. using System.Web.Http;
  2. using WebActivatorEx;
  3. using Central.Control.WebApi;
  4. using Swashbuckle.Application;
  5. [assembly: PreApplicationStartMethod(typeof(SwaggerConfig), "Register")]
  6. namespace Central.Control.WebApi
  7. {
  8. /// <summary>
  9. ///
  10. /// </summary>
  11. public class SwaggerConfig
  12. {
  13. /// <summary>
  14. ///
  15. /// </summary>
  16. public static void Register()
  17. {
  18. var thisAssembly = typeof(SwaggerConfig).Assembly;
  19. GlobalConfiguration.Configuration
  20. .EnableSwagger(c =>
  21. {
  22. c.SingleApiVersion("v1", "Central.Control.WebApi");
  23. c.IncludeXmlComments(string.Format("{0}/App_Data/Central.Control.WebApi.xml", System.AppDomain.CurrentDomain.BaseDirectory));//ÉèÖÃxmlµØÖ·
  24. // By default, the service root url is inferred from the request used to access the docs.
  25. // However, there may be situations (e.g. proxy and load-balanced environments) where this does not
  26. // resolve correctly. You can workaround this by providing your own code to determine the root URL.
  27. //
  28. //c.RootUrl(req => GetRootUrlFromAppConfig());
  29. // If schemes are not explicitly provided in a Swagger 2.0 document, then the scheme used to access
  30. // the docs is taken as the default. If your API supports multiple schemes and you want to be explicit
  31. // about them, you can use the "Schemes" option as shown below.
  32. //
  33. //c.Schemes(new[] { "http", "https" });
  34. // Use "SingleApiVersion" to describe a single version API. Swagger 2.0 includes an "Info" object to
  35. // hold additional metadata for an API. Version and title are required but you can also provide
  36. // additional fields by chaining methods off SingleApiVersion.
  37. //
  38. c.SingleApiVersion("v1", "Central.Control.WebApi");
  39. // If you want the output Swagger docs to be indented properly, enable the "PrettyPrint" option.
  40. //
  41. //c.PrettyPrint();
  42. // If your API has multiple versions, use "MultipleApiVersions" instead of "SingleApiVersion".
  43. // In this case, you must provide a lambda that tells Swashbuckle which actions should be
  44. // included in the docs for a given API version. Like "SingleApiVersion", each call to "Version"
  45. // returns an "Info" builder so you can provide additional metadata per API version.
  46. //
  47. //c.MultipleApiVersions(
  48. // (apiDesc, targetApiVersion) => ResolveVersionSupportByRouteConstraint(apiDesc, targetApiVersion),
  49. // (vc) =>
  50. // {
  51. // vc.Version("v2", "Swashbuckle Dummy API V2");
  52. // vc.Version("v1", "Swashbuckle Dummy API V1");
  53. // });
  54. // You can use "BasicAuth", "ApiKey" or "OAuth2" options to describe security schemes for the API.
  55. // See https://github.com/swagger-api/swagger-spec/blob/master/versions/2.0.md for more details.
  56. // NOTE: These only define the schemes and need to be coupled with a corresponding "security" property
  57. // at the document or operation level to indicate which schemes are required for an operation. To do this,
  58. // you'll need to implement a custom IDocumentFilter and/or IOperationFilter to set these properties
  59. // according to your specific authorization implementation
  60. //
  61. //c.BasicAuth("basic")
  62. // .Description("Basic HTTP Authentication");
  63. //
  64. // NOTE: You must also configure 'EnableApiKeySupport' below in the SwaggerUI section
  65. //c.ApiKey("apiKey")
  66. // .Description("API Key Authentication")
  67. // .Name("apiKey")
  68. // .In("header");
  69. //
  70. //c.OAuth2("oauth2")
  71. // .Description("OAuth2 Implicit Grant")
  72. // .Flow("implicit")
  73. // .AuthorizationUrl("http://petstore.swagger.wordnik.com/api/oauth/dialog")
  74. // //.TokenUrl("https://tempuri.org/token")
  75. // .Scopes(scopes =>
  76. // {
  77. // scopes.Add("read", "Read access to protected resources");
  78. // scopes.Add("write", "Write access to protected resources");
  79. // });
  80. // Set this flag to omit descriptions for any actions decorated with the Obsolete attribute
  81. //c.IgnoreObsoleteActions();
  82. // Each operation be assigned one or more tags which are then used by consumers for various reasons.
  83. // For example, the swagger-ui groups operations according to the first tag of each operation.
  84. // By default, this will be controller name but you can use the "GroupActionsBy" option to
  85. // override with any value.
  86. //
  87. //c.GroupActionsBy(apiDesc => apiDesc.HttpMethod.ToString());
  88. // You can also specify a custom sort order for groups (as defined by "GroupActionsBy") to dictate
  89. // the order in which operations are listed. For example, if the default grouping is in place
  90. // (controller name) and you specify a descending alphabetic sort order, then actions from a
  91. // ProductsController will be listed before those from a CustomersController. This is typically
  92. // used to customize the order of groupings in the swagger-ui.
  93. //
  94. //c.OrderActionGroupsBy(new DescendingAlphabeticComparer());
  95. // If you annotate Controllers and API Types with
  96. // Xml comments (http://msdn.microsoft.com/en-us/library/b2s063f7(v=vs.110).aspx), you can incorporate
  97. // those comments into the generated docs and UI. You can enable this by providing the path to one or
  98. // more Xml comment files.
  99. //
  100. //c.IncludeXmlComments(GetXmlCommentsPath());
  101. // Swashbuckle makes a best attempt at generating Swagger compliant JSON schemas for the various types
  102. // exposed in your API. However, there may be occasions when more control of the output is needed.
  103. // This is supported through the "MapType" and "SchemaFilter" options:
  104. //
  105. // Use the "MapType" option to override the Schema generation for a specific type.
  106. // It should be noted that the resulting Schema will be placed "inline" for any applicable Operations.
  107. // While Swagger 2.0 supports inline definitions for "all" Schema types, the swagger-ui tool does not.
  108. // It expects "complex" Schemas to be defined separately and referenced. For this reason, you should only
  109. // use the "MapType" option when the resulting Schema is a primitive or array type. If you need to alter a
  110. // complex Schema, use a Schema filter.
  111. //
  112. //c.MapType<ProductType>(() => new Schema { type = "integer", format = "int32" });
  113. // If you want to post-modify "complex" Schemas once they've been generated, across the board or for a
  114. // specific type, you can wire up one or more Schema filters.
  115. //
  116. //c.SchemaFilter<ApplySchemaVendorExtensions>();
  117. // In a Swagger 2.0 document, complex types are typically declared globally and referenced by unique
  118. // Schema Id. By default, Swashbuckle does NOT use the full type name in Schema Ids. In most cases, this
  119. // works well because it prevents the "implementation detail" of type namespaces from leaking into your
  120. // Swagger docs and UI. However, if you have multiple types in your API with the same class name, you'll
  121. // need to opt out of this behavior to avoid Schema Id conflicts.
  122. //
  123. //c.UseFullTypeNameInSchemaIds();
  124. // Alternatively, you can provide your own custom strategy for inferring SchemaId's for
  125. // describing "complex" types in your API.
  126. //
  127. //c.SchemaId(t => t.FullName.Contains('`') ? t.FullName.Substring(0, t.FullName.IndexOf('`')) : t.FullName);
  128. // Set this flag to omit schema property descriptions for any type properties decorated with the
  129. // Obsolete attribute
  130. //c.IgnoreObsoleteProperties();
  131. // In accordance with the built in JsonSerializer, Swashbuckle will, by default, describe enums as integers.
  132. // You can change the serializer behavior by configuring the StringToEnumConverter globally or for a given
  133. // enum type. Swashbuckle will honor this change out-of-the-box. However, if you use a different
  134. // approach to serialize enums as strings, you can also force Swashbuckle to describe them as strings.
  135. //
  136. //c.DescribeAllEnumsAsStrings();
  137. // Similar to Schema filters, Swashbuckle also supports Operation and Document filters:
  138. //
  139. // Post-modify Operation descriptions once they've been generated by wiring up one or more
  140. // Operation filters.
  141. //
  142. //c.OperationFilter<AddDefaultResponse>();
  143. //
  144. // If you've defined an OAuth2 flow as described above, you could use a custom filter
  145. // to inspect some attribute on each action and infer which (if any) OAuth2 scopes are required
  146. // to execute the operation
  147. //
  148. //c.OperationFilter<AssignOAuth2SecurityRequirements>();
  149. // Post-modify the entire Swagger document by wiring up one or more Document filters.
  150. // This gives full control to modify the final SwaggerDocument. You should have a good understanding of
  151. // the Swagger 2.0 spec. - https://github.com/swagger-api/swagger-spec/blob/master/versions/2.0.md
  152. // before using this option.
  153. //
  154. //c.DocumentFilter<ApplyDocumentVendorExtensions>();
  155. // In contrast to WebApi, Swagger 2.0 does not include the query string component when mapping a URL
  156. // to an action. As a result, Swashbuckle will raise an exception if it encounters multiple actions
  157. // with the same path (sans query string) and HTTP method. You can workaround this by providing a
  158. // custom strategy to pick a winner or merge the descriptions for the purposes of the Swagger docs
  159. //
  160. //c.ResolveConflictingActions(apiDescriptions => apiDescriptions.First());
  161. // Wrap the default SwaggerGenerator with additional behavior (e.g. caching) or provide an
  162. // alternative implementation for ISwaggerProvider with the CustomProvider option.
  163. //
  164. //c.CustomProvider((defaultProvider) => new CachingSwaggerProvider(defaultProvider));
  165. })
  166. .EnableSwaggerUi(c =>
  167. {
  168. // Use the "DocumentTitle" option to change the Document title.
  169. // Very helpful when you have multiple Swagger pages open, to tell them apart.
  170. //
  171. //c.DocumentTitle("My Swagger UI");
  172. // Use the "InjectStylesheet" option to enrich the UI with one or more additional CSS stylesheets.
  173. // The file must be included in your project as an "Embedded Resource", and then the resource's
  174. // "Logical Name" is passed to the method as shown below.
  175. //
  176. //c.InjectStylesheet(containingAssembly, "Swashbuckle.Dummy.SwaggerExtensions.testStyles1.css");
  177. // Use the "InjectJavaScript" option to invoke one or more custom JavaScripts after the swagger-ui
  178. // has loaded. The file must be included in your project as an "Embedded Resource", and then the resource's
  179. // "Logical Name" is passed to the method as shown above.
  180. //
  181. //c.InjectJavaScript(thisAssembly, "Swashbuckle.Dummy.SwaggerExtensions.testScript1.js");
  182. // The swagger-ui renders boolean data types as a dropdown. By default, it provides "true" and "false"
  183. // strings as the possible choices. You can use this option to change these to something else,
  184. // for example 0 and 1.
  185. //
  186. //c.BooleanValues(new[] { "0", "1" });
  187. // By default, swagger-ui will validate specs against swagger.io's online validator and display the result
  188. // in a badge at the bottom of the page. Use these options to set a different validator URL or to disable the
  189. // feature entirely.
  190. //c.SetValidatorUrl("http://localhost/validator");
  191. //c.DisableValidator();
  192. // Use this option to control how the Operation listing is displayed.
  193. // It can be set to "None" (default), "List" (shows operations for each resource),
  194. // or "Full" (fully expanded: shows operations and their details).
  195. //
  196. //c.DocExpansion(DocExpansion.List);
  197. // Specify which HTTP operations will have the 'Try it out!' option. An empty paramter list disables
  198. // it for all operations.
  199. //
  200. //c.SupportedSubmitMethods("GET", "HEAD");
  201. // Use the CustomAsset option to provide your own version of assets used in the swagger-ui.
  202. // It's typically used to instruct Swashbuckle to return your version instead of the default
  203. // when a request is made for "index.html". As with all custom content, the file must be included
  204. // in your project as an "Embedded Resource", and then the resource's "Logical Name" is passed to
  205. // the method as shown below.
  206. //
  207. //c.CustomAsset("index", containingAssembly, "YourWebApiProject.SwaggerExtensions.index.html");
  208. // If your API has multiple versions and you've applied the MultipleApiVersions setting
  209. // as described above, you can also enable a select box in the swagger-ui, that displays
  210. // a discovery URL for each version. This provides a convenient way for users to browse documentation
  211. // for different API versions.
  212. //
  213. //c.EnableDiscoveryUrlSelector();
  214. // If your API supports the OAuth2 Implicit flow, and you've described it correctly, according to
  215. // the Swagger 2.0 specification, you can enable UI support as shown below.
  216. //
  217. //c.EnableOAuth2Support(
  218. // clientId: "test-client-id",
  219. // clientSecret: null,
  220. // realm: "test-realm",
  221. // appName: "Swagger UI"
  222. // //additionalQueryStringParams: new Dictionary<string, string>() { { "foo", "bar" } }
  223. //);
  224. // If your API supports ApiKey, you can override the default values.
  225. // "apiKeyIn" can either be "query" or "header"
  226. //
  227. //c.EnableApiKeySupport("apiKey", "header");
  228. });
  229. }
  230. }
  231. }