یک نکته‌ی تکمیلی
اگر با استفاده از قالب پیش‌فرض تولید Web API در NET 5. پروژه‌ای را ایجاد کنید (dotnet new webapi)، به صورت پیش‌فرض به همراه Swashbuckle.AspNetCore ارائه می‌شود:
<Project Sdk="Microsoft.NET.Sdk.Web">
  <PropertyGroup>
    <TargetFramework>net5.0</TargetFramework>
  </PropertyGroup>

  <ItemGroup>
    <PackageReference Include="Swashbuckle.AspNetCore" Version="5.5.1" />
  </ItemGroup>
</Project>
خطای 500 یعنی internal server error. بنابراین در کدهای سمت سرور شما مشکلی رخ داده که باید آن‌را لاگ و بررسی کنید. همچنین ابزار developer tools مرورگر در برگه‌ی network آن با انتخاب response خطا دار، ممکن است در برگه‌ی نمایش محتوای response، حاوی اصل خطای بازگشتی از سرور هم باشد.
‫۴ سال قبل، شنبه ۲۹ شهریور ۱۳۹۹، ساعت ۱۴:۱۸
بر اساس اهدافی که این مطلب دنبال می‌کند، مشکلی مشاهده نشد. (هدف از این مطلب هم فقط استفاده از یک منبع اشتراکی هست وکار با Web API (ذکر شده در عنوان مطلب و مقدمه‌ی مطلب)؛ که اساسا ویژگی Display برای آن معنایی ندارد و مخصوص MVC هست و صفحات Razor. همچنین اگر قرار باشد دوبار این تعریف نام خاصیت انجام شود (یکبار پارامتری و یکبار در ویژگی Display)، اساسا چه نیازی به تعریف دوم هست؟ همان نام را بجای پارامتر قرار دادن بهتر هست و پارامتری کار کردن در اینجا هیچ مزیتی ندارد)
مدل مثال جاری به این صورت تغییر کرد: ( مثال کامل Core3xSharedResource-V2.zip )
using System.ComponentModel.DataAnnotations;

namespace Core3xSharedResource.Models.Account
{
    public class RegisterModel
    {
        [Required(ErrorMessage = "Please enter an email address")] // -->> from the shared resources
        [EmailAddress(ErrorMessage = "Please enter a valid email address")] // -->> from the shared resources
        public string Email { get; set; }

        [Required(ErrorMessage = "The {0} field is required")]
        [Display(Name = "User Name")]
        public string UserName { get; set; }
    }
}
نام خاصیت یکبار پارامتری تعریف شده و یکبار قرار است از ویژگی Display دریافت شود (یک کار اضافی و بی‌مفهوم در Web API که Viewهای آن قرار است توسط React یا Angular تامین شوند و نه الزاما توسط صفحات Razor که می‌توانند با ویژگی Display کار کنند)؛ با این مداخل متناظر جدید در فایل منبع اشتراکی:
<?xml version="1.0" encoding="utf-8"?>
<root>
  <data name="Please enter an email address" xml:space="preserve">
    <value>لطفا ایمیلی را وارد کنید</value>
  </data>
  <data name="Please enter a valid email address" xml:space="preserve">
    <value>لطفا ایمیل معتبری را وارد کنید</value>
  </data>
  <data name="The {0} field is required" xml:space="preserve">
    <value>{0} را تکمیل کنید</value>
  </data>
  <data name="User Name" xml:space="preserve">
    <value>نام کاربری</value>
  </data>
</root>
پس از ارسال یک Post خالی به سمت اکشن متد یکی از کنترلرهای مثال، این خروجی کاملا بومی سازی شده قابل مشاهده‌است:

ضمن اینکه اگر کسی بخواهد کار جدی اعتبارسنجی را در Web API انجام دهد بهتر است از Fluent Validation استفاده کند (که تبدیل به یک استاندارد برای آن شده‌است).

نگارش 5.6 آن به صورت رسمی از YAML پشتیبانی می‌کند (Support for emitting Swagger / OpenAPI in yaml format). روش استفاده:
app.UseSwaggerUI(x => { x.SwaggerEndpoint("/swagger/v1/swagger.yaml", "Zeipt Dashboard API"); });
‫۴ سال قبل، چهارشنبه ۱۹ شهریور ۱۳۹۹، ساعت ۱۵:۲۲
یک نکته‌ی تکمیلی
اگر در حین refactoring و استخراج متدها، به متدی با تعداد پارامترهای بالا رسیدید و این متد هم نیازی نبود به کلاس دیگری منتقل شود، می‌توان برای کاهش تعداد پارامترهای آن از قابلیت «C# 7 - Local Functions» هم استفاده کرد. یک متد محلی به پارامترهای تعریف شده‌ی در متد دربرگیرنده‌ی آن دسترسی دارد.