پیشتر مطلبی در این زمینه در سایت منتشر شد که به خوبی نحوهی پیاده سازی Swagger را در یک برنامهی ASP.NET Web API نشان میدهد. حال در این مقالهی کوتاه میخواهیم نحوهی پیاده سازی آن را در یک برنامهی مبتنی بر ASP.NET Core بررسی کنیم.
در این صورت خروجی به شکل زیر نمایش داده خواهد شد که حاوی اطلاعات بسیار مفیدی در مورد APIها میباشد. اطلاعاتی شامل http method ، آدرس API، پارامترهای ورودی، مدل خروجی و ...
دریافت Swagger از نوگت
ابتدا باید این پکیج را از آدرسش در نیوگت بگیریم و در برنامهی خود نصب کنیم:
pm> Install-Package Swashbuckle.AspNetCore
پیکربندی برنامه
برای کانفیگ Swagger و تولید خودکار و پویای مستندات APIها توسط آن باید تنظیمات زیر را در کلاس Startup برنامه انجام دهیم :
using Microsoft.AspNetCore.Mvc; using Swashbuckle.AspNetCore.Swagger; namespace MyProject.Web.Api { public class Startup { public IServiceProvider ConfigureServices(IServiceCollection services) { // Register the Swagger generator, defining one or more Swagger documents services.AddSwaggerGen(c => { c.SwaggerDoc("v1", new Info { Title = "MyProject API Documentation", Version = "v1" }); }); } public void Configure(IApplicationBuilder app, IHostingEnvironment env, IServiceScopeFactory serviceScopeFactory) { // Enable middleware to serve generated Swagger as a JSON endpoint. app.UseSwagger(); // Enable middleware to serve swagger-ui (HTML, JS, CSS, etc.), specifying the Swagger JSON endpoint. app.UseSwaggerUI(c => { c.SwaggerEndpoint("/swagger/v1/swagger.json", "My API V1"); }); } } }
مشاهده خروجی مستند سازی API ها
بعد از اینکه کانفیگهای فوق را انجام دادیم کافی است تا برنامه را اجرا کرده و آدرس زیر را در مرورگر وارد کنیم:
http://localhost:port/swagger
در صورت استفاده از SWagger ، ذکر [HttpGet] برای APIهای GET اجباری میشود و در صورتیکه این مورد را برای API ای مشخص نکرده باشیم با خطای Run Time مواجه شده و برنامه اجرا نخواهد شد.
اشتراکها
برنامه SourceTree
Here are some of the reasons why nullable reference types are less than ideal:
- Invoking a member on a null value will issue a System.NullReferenceException exception, and every invocation that results in a System.NullReferenceException in production code is a bug. Unfortunately, however, with nullable reference types we “fall in” to doing the wrong thing rather than the right thing. The “fall in” action is to invoke a reference type without checking for null.
- There’s an inconsistency between reference types and value types (following the introduction of Nullable<T>) in that value types are nullable when decorated with “?” (for example, int? number); otherwise, they default to non-nullable. In contrast, reference types are nullable by default. This is “normal” to those of us who have been programming in C# for a long time, but if we could do it all over, we’d want the default for reference types to be non-nullable and the addition of a “?” to be an explicit way to allow nulls.
- It’s not possible to run static flow analysis to check all paths regarding whether a value will be null before dereferencing it, or not. Consider, for example, if there were unmanaged code invocations, multi-threading, or null assignment/replacement based on runtime conditions. (Not to mention whether analysis would include checking of all library APIs that are invoked.)
- There’s no reasonable syntax to indicate that a reference type value of null is invalid for a particular declaration.
- There’s no way to decorate parameters to not allow null.
Use the modern Materialize framework, together with jQuery , jQuery Timepicker and Hammer.js
for touch events. Materialize turns the plain looking standard HTML
input fields into these awesome Android-like switches and check
boxes. It also adds the the on-click wave ink effect as it has Waves.js included in it’s package. Demo
اشتراکها