بله. در همان قسمت switch (entry.State) کدهای فوق، property.CurrentValue به مقدار جدید اشاره می‌کند و property.OriginalValue به مقدار قبلی. می‌توانید دو دیکشنری برای جمع آوری اطلاعات این دو تهیه کنید (در کدهای فوق فقط یک لیست auditEntry.AuditProperties هست که مقادیر جدید را جمع آوری می‌کند) و سپس در یک جدول ثالث، مقدار JSON متناظر با این Dictionaryها را در مرحله‌ی auditEntry.AuditProperties.ToDictionary کدهای فوق، در دو فیلد NewValue و OldValue آن ذخیره کنید.

پیاده سازی ارائه شده، برگرفته است از مطلب «اعتبارسنجی مبتنی بر JWT در ASP.NET Core 2.0 بدون استفاده از سیستم Identity»

این سؤال بیشتر مرتبط هست به مطلب «معرفی JSON Web Token» و تفاوت‌های آن با یک Guid، در داشتن امضای دیجیتال جهت اطمینان حاصل کردن از عدم دستکاری آن توسط کاربر، داشتن تاریخ انقضاء، تا امکان قرار دادن Claims و نقش‌های کاربر در آن جهت استفاده‌ی در برنامه‌های SPA و ... است. 

خیر. دستور استفاده از فایل proxy.config.json هنوز هم در آدرس  http://localhost:4200 اجرا می‌شود (یعنی پورت آن هنوز هم 4200 است)، اما target درخواست‌ها را به صورت خودکار بر اساس تنظیمات فایل json یاد شده تنظیم و بازنویسی می‌کند (نه پورت وب سرور آزمایشی آن‌را).

آیا پس از توزیع یک برنامه آنگولار تک صفحه ای صرفا با اجرای index.html در مرورگر بدون نیاز به وب سرور ( در مواردی مانند web api که داده‌ها یه صورت json و از راه دور تامین می‌شوند ) مشکلی نخواهد بود و مواردی مانند مسیریابی صرفا توسط جاوا اسکریپت هندل خواهند شد ؟

در واقع در WebApi پاسخها را با فرمتهای مختلف که بخوایم مثلا CSV ، میتونیم فرمت کنیم اما در WCF REST  فقط xml و json  را داریم؟ اگه اینطوری باشه ما دیگه میتونیم WCF REST را deprecate   بدانیم؟ چون دیگه لزومی به استفاده از آن وجود نداره؟.

- نگارش مورد استفاده در این سری «بتا 15» است. بنابراین آنچنان شاهد تغییرات اساسی در API در دسترس آن نخواهید بود.
همچنین نگارش نهایی آن هم به زودی در دسترس خواهد بود.
+ زمانیکه قرار است از فریم ورک‌های جاوا اسکریپتی SPA یا Single page applications مانند AngularJS استفاده شود، عملا دات نت تبدیل خواهد شد به فراهم کننده‌ی اطلاعات و دریافت کننده‌ی اطلاعات و نه بیشتر. بنابراین حداکثر به یک وب سرور نیاز خواهد بود؛ به همراه فناوری که بتواند JSON تولید کند (ارسال data به کلاینت) و JSON دریافت کند (دریافت data از کاربر). در این حالت اهمیتی ندارد که از MVC استفاده کنید یا از ASP.NET Web API و یا ... هر فناوری سمت سرور دیگری. همینقدر که این فناوری بتواند خروجی JSON را پردازش کند و یا در کنار آن وب سروری هم جهت هاست سایت فراهم باشد، کافی است.
یعنی در این حالت قابلیت‌های رندر HTML فناوری‌هایی مانند ASP.NET MVC و هم ASP.NET Web forms فراموش خواهند شد؛ چون استفاده‌ای از توانمندی‌های آن‌ها نخواهیم کرد.
استفاده از فریم ورک‌های SPA یعنی آزادی انتخاب نحوه‌ی ندر HTML نهایی و مدیریت فعالیت‌های کاربران در سمت کاربر. سمت سرور آن هم چیزی بیشتر از دریافت و یا ارسال data با فرمت JSON نیست.

- اتفاقا برعکس است. چون از سرور محتوای JSON را دریافت می‌کنید (Data)، حجم کمتری نسبت به HTML نهایی رندر شده‌ی در سمت سرور (HTML+Data) دارد.
- از سال 2014، گوگل شروع به پردازش جاوا اسکریپت موجود در صفحات وب هم کرده‌است. بنابراین مشکلی با این نوع برنامه‌ها ندارد.