{"id":11305,"date":"2018-02-02T10:00:52","date_gmt":"2018-02-02T18:00:52","guid":{"rendered":"https:\/\/blogs.msdn.microsoft.com\/webdev\/?p=11305"},"modified":"2021-11-01T03:48:28","modified_gmt":"2021-11-01T10:48:28","slug":"asp-net-core-2-1-roadmap","status":"publish","type":"post","link":"https:\/\/devblogs.microsoft.com\/dotnet\/asp-net-core-2-1-roadmap\/","title":{"rendered":"ASP.NET Core 2.1 roadmap"},"content":{"rendered":"<p>Five months ago, we shipped ASP.NET Core 2.0 as a foundational release for our high performance, cross-platform web framework for .NET and .NET Core. Since then we have been hard at work to deliver the next wave of features in ASP.NET Core 2.1. Below is an outline of the features and improvements that are planned for this release, which is targeted for mid-year 2018.<\/p>\n<p>Contents:<\/p>\n<ul>\n<li><a href=\"#mvc\">MVC<\/a><\/li>\n<li><a href=\"#signalr\">SignalR<\/a><\/li>\n<li><a href=\"#webhooks\">WebHooks<\/a><\/li>\n<li><a href=\"#gdpr\">GDPR<\/a><\/li>\n<li><a href=\"#security\">Security<\/a><\/li>\n<li><a href=\"#identity\">Identity<\/a><\/li>\n<li><a href=\"#options\">Options improvements<\/a><\/li>\n<li><a href=\"#httpclientfactory\">HttpClientFactory<\/a><\/li>\n<li><a href=\"#kestrel\">Kestrel<\/a><\/li>\n<li><a href=\"#ancm\">ASP.NET Core Module<\/a><\/li>\n<li><a href=\"#app\">New Microsoft.AspNetCore.App package<\/a><\/li>\n<\/ul>\n<p>You can read about the roadmap for <a href=\"https:\/\/blogs.msdn.microsoft.com\/dotnet\/2018\/02\/02\/net-core-2-1-roadmap\/\">.NET Core 2.1<\/a> and <a href=\"https:\/\/devblogs.microsoft.com\/dotnet\/entity-framework-core-2-1-roadmap\/\">EF Core 2.1<\/a> on the .NET team blog.<\/p>\n<p>A few of us also recorded an <a href=\"https:\/\/channel9.msdn.com\/Shows\/On-NET\">On.NET<\/a> show to introduce .NET Core 2.1, ASP.NET Core 2.1, and EF Core 2.1 in the Channel 9 studios, in two parts (<a href=\"https:\/\/channel9.msdn.com\/Shows\/On-NET\/NET-Core-21-Roadmap-PT1\">roadmap<\/a>, <a href=\"https:\/\/channel9.msdn.com\/Shows\/On-NET\/NET-Core-21-Roadmap-PT2\">demos<\/a>). The roadmap part is shown below:<\/p>\n<p style=\"text-align: center\">\n<iframe width=\"540\" height=\"320\" src=\"https:\/\/channel9.msdn.com\/Shows\/On-NET\/NET-Core-21-Roadmap-PT1\/player\" allowfullscreen><\/iframe>\n<\/p>\n<h3 id=\"mvc\">MVC<\/h3>\n<h4>Razor Pages improvements<\/h4>\n<p>In ASP.NET Core 2.0 we introduced Razor Pages as a new paged-based model for building Web UI. In 2.1 we are making a variety of improvements to Razor Pages to make it even more productive.<\/p>\n<h5>Razor Pages in an area<\/h5>\n<p>Areas provide a way to partition a large MVC app into smaller functional groupings each with their own controllers and views. In 2.1 we will add support for areas to Razor Pages so that areas can have their own pages directory.<\/p>\n<h5>Support for \/Pages\/Shared<\/h5>\n<p>In 2.1 Razor Pages will fall back to finding Razor assets such as layouts and partials in <code>\/[pages root]\/Shared<\/code> before falling back to <code>\/Views\/Shared<\/code>.<\/p>\n<h5>Bind all properties on a page or controller<\/h5>\n<p>Starting in 2.0 you could use the <code>BindPropertyAttribute<\/code> to specify that a property on a page model or controller should be bound to data from the request. If you have lots of properties that you want to bind, then this can get tedious and verbose. In 2.1 we will add support for specifying that all properties on a page or controller should be bound by putting the <code>BindPropertyAttribute<\/code> on the class.<\/p>\n<h5>Implement IPageFilter on page models<\/h5>\n<p>We will implement <code>IPageFilter<\/code> on page models, so that you can run logic before or after page handlers run for a given request, much the same way that you can implement <code>IActionFilter<\/code> on a controller.<\/p>\n<h4>Functional testing infrastructure<\/h4>\n<p>Writing functional tests for an MVC app allows you to test handling of a request end-to-end including running routing, filters, controllers, actions, views and pages. While writing in-memory functional tests for MVC apps is possible with ASP.NET Core 2.0 it requires <a href=\"https:\/\/blogs.msdn.microsoft.com\/webdev\/2017\/12\/07\/testing-asp-net-core-mvc-web-apps-in-memory\/\"> significant setup<\/a>.<\/p>\n<p>For 2.1 we will provide an test fixture implementation that handles the typical pitfalls when trying to test MVC applications using <a href=\"https:\/\/docs.microsoft.com\/en-us\/aspnet\/core\/testing\/integration-testing\">TestServer<\/a>:<\/p>\n<ul>\n<li>Copy the .deps file from your project into the test assembly bin folder<\/li>\n<li>Specify the content root of the application&#8217;s project root so that static files and views can be found<\/li>\n<li>Streamline setting up your app on TestServer<\/li>\n<\/ul>\n<p>A sample test that uses the new test fixture with xUnit looks like this:\n<\/p>\n<p>See <a href=\"https:\/\/github.com\/aspnet\/announcements\/issues\/275\">https:\/\/github.com\/aspnet\/announcements\/issues\/275<\/a> for additional details.<\/p>\n<h4>Web API improvements<\/h4>\n<p>ASP.NET Core gives you a single unified framework for building both Web UI and Web APIs. In 2.1 we are making various improvements to the\nframework for building Web APIs.<\/p>\n<h5>Better Input Processing<\/h5>\n<p>We want the experience around invalid input to be more automatic and more consistent. More concretely we&#8217;re going to:<\/p>\n<ul>\n<li>Create a programming model where your action code isn&#8217;t called when a request has validation errors (see \u201cEnhanced Web API controller conventions\u201d below)<\/li>\n<li>Improve the fidelity of error responses when the request body fails to deserialize or the JSON is invalid<\/li>\n<li>Enable placing validation attributes directly on action parameters<\/li>\n<\/ul>\n<h5>Support for Problem Details<\/h5>\n<p>We are adding support for <a href=\"https:\/\/tools.ietf.org\/html\/rfc7807\">RFC 7808 &#8211; Problem Details for HTTP APIs<\/a> as a standardized format for returning machine readable error responses from HTTP APIs. You can return a Problem Details response from your API action using the <code>ValidationProblem()<\/code> helper method.<\/p>\n<h5>Improved OpenAPI specification support<\/h5>\n<p>We want to embrace the <a href=\"https:\/\/github.com\/OAI\/OpenAPI-Specification\">OpenAPI specification<\/a> (previously called \u201cSwagger\u201d) and make Web APIs built with ASP.NET Core more descriptive. Today you need a lot of \u201cattribute soup\u201d to get a reasonable OpenAPI spec from ASP.NET Core. We plan to introduce an opinionated layer that infers the possible responses based on what you&#8217;re likely to have done with your actions (attributes still win when you want to be explicit).<\/p>\n<p>For example, actions that return <code>IActionResult<\/code> need to be attributed to indicate the return type so that the schema of the response body can be determined. Actions that return the response type directly don\u2019t need to be attributed, but then you lose the flexibility to return any action result.<\/p>\n<p>We will introduce a new <code>ActionResult&lt;T&gt;<\/code> type that allows you to return either the response type or any action result, while still indicating the response type.<\/p>\n<h5>Enhanced Web API controller conventions and ActionResult&lt;T&gt;<\/h5>\n<p>We are adding the <code>[ApiController]<\/code> attribute as the way to opt-in to Web API specific conventions and behaviors. These behaviors include:<\/p>\n<ul>\n<li>Automatically responding with a 400 when validation errors occur<\/li>\n<li>Infer smarter defaults for action parameters: <code>[FromBody]<\/code> for complex types, <code>[FromRoute]<\/code> when possible, otherwise <code>[FromQuery]<\/code><\/li>\n<li>Requires attribute routing \u2013 actions are not accessible by convention-based routes<\/li>\n<\/ul>\n<p>Here\u2019s an example Web API controller that uses these new enhancements:\n<\/p>\n<p>Here\u2019s what the Web API would look like if you were to implement it with 2.0:\n<\/p>\n<h5>JSON Patch improvements<\/h5>\n<p>For <a href=\"http:\/\/jsonpatch.com\/\">JSON Patch<\/a> we will add support for the test operator and for patching dictionaries with non-string keys.<\/p>\n<h5>Partial Tag Helper<\/h5>\n<p><a href=\"https:\/\/docs.microsoft.com\/en-us\/aspnet\/core\/mvc\/views\/partial\">Razor partial views<\/a> are a convenient way to include some Razor content into a view or page. Today there are four different methods for rendering a partial on a page that have different trade-offs and limitations (<code>Html.Partial<\/code> vs <code>Html.RenderPartial<\/code>, sync vs async). Rendering partials also suffers from a limitation where the generated prefix for rendered form elements based on the given model, must be handled manually for each partial rendering.<\/p>\n<p>The new partial Tag Helper makes rendering a partial straightforward and elegant. You can specify the model using model expression syntax and the partial Tag Helper will handle setting up the correct HTML field prefix for you:<\/p>\n<\/p>\n<h4>Razor UI in a class library<\/h4>\n<p>ASP.NET Core 2.1 will make it easier to build and include Razor based UI in a library and share it across multiple projects. A new Razor SDK will enable building Razor files into a class library project that can then be packaged into a NuGet package. Views and pages in libraries will automatically be discovered and can be overridden by the application. By integrating Razor compilation into the build, the app startup time is also significantly faster, while still allowing for fast updates to your Razor views and pages at runtime as part of an iterative development workflow.<\/p>\n<h3 id=\"signalr\">SignalR<\/h3>\n<p>For ASP.NET Core 2.1 we are porting ASP.NET SignalR to ASP.NET Core to support real-time web scenarios. As previously <a href=\"https:\/\/devblogs.microsoft.com\/aspnet\/announcing-signalr-for-asp-net-core-2-0\/\">announced<\/a>, ASP.NET Core SignalR will also include a number of improvements, including a simplified scale-out model, a new JavaScript client with no jQuery dependency, a new compact binary protocol based on <a href=\"http:\/\/msgpack.org\/\">MessagePack<\/a>, support for custom protocols, a new streaming response model, and support for clients based on bare WebSockets. You can start trying out ASP.NET Core SignalR today by checking out the <a href=\"https:\/\/github.com\/aspnet\/signalr-samples\">samples<\/a>.<\/p>\n<h3 id=\"webhooks\">WebHooks<\/h3>\n<p>WebHooks are a lightweight HTTP pattern for event notification across the web. WebHooks enable services to send event notifications over HTTP to registered subscribers. For 2.1 we are porting a subset of the ASP.NET WebHooks receivers to ASP.NET Core in a way that integrates with the ASP.NET Core idioms.<\/p>\n<p>For 2.1 we plan to port the following receivers:<\/p>\n<ul>\n<li>Microsoft Azure alerts<\/li>\n<li>Microsoft Azure Kudu notifications<\/li>\n<li>Microsoft Dynamics CRM<\/li>\n<li>Bitbucket<\/li>\n<li>Dropbox<\/li>\n<li>GitHub<\/li>\n<li>MailChimp<\/li>\n<li>Pusher<\/li>\n<li>Salesforce<\/li>\n<li>Slack<\/li>\n<li>Stripe<\/li>\n<li>Trello<\/li>\n<li>WordPress<\/li>\n<\/ul>\n<p>To use a WebHook receiver in ASP.NET Core WebHooks you attribute a controller action that you want to handle the notification. For example, here\u2019s how you can handle an Azure alert:\n<\/p>\n<h3 id=\"gdpr\">Improvements for GDPR<\/h3>\n<p>The ASP.NET Core 2.1 project templates will include some extension points to help you meet some of your UE General Data Protection Regulation (GDPR) requirements.<\/p>\n<p>A new cookie consent feature will allow you to ask for (and track) consent from your users for storing personal information. This can be combined with a new cookie feature where cookies can be marked as essential or non-essential. If a user has not consented to data collection, non-essential cookies will not be sent to the browser. You will still need to create the wording on the UI prompt and a suitable privacy policy which matches the GDPR analysis you or your company have performed, along with implementing the logic for determining under what conditions a given user should be asked for consent before writing non-essential cookies (the templates simply default to asking all users).<\/p>\n<p>Additionally, the ASP.NET Core Identity templates for individual authentication now have a UI to allow users to download their personal data, along with the ability to delete their account entirely. By default, these UI areas only return personal information from ASP.NET Core identity, and perform a delete on the identity tables. As you add your own information into your database you should extend these features to also include that data according to your GDPR analysis.<\/p>\n<p>Finally, we are considering extension points to allow you to apply your own encryption of ASP.NET Core identity data. We recommend that you examine the encryption features of your database to see if they match your GDPR requirements before attempting to layer on your own encryption mechanisms. Both Microsoft SQL and SQL Azure, as well as Azure table storage offer transparent encryption of data at rest, which does not require any changes to your application and is managed for you.<\/p>\n<h3 id=\"security\">Security<\/h3>\n<h4>HTTPS<\/h4>\n<p>With the increased focus on security and privacy, enabling HTTPS for web apps is more important than ever before. HTTPS enforcement is becoming increasingly <a href=\"https:\/\/blog.chromium.org\/2017\/04\/next-steps-toward-more-connection.html\">strict<\/a> on the web, and sites that don\u2019t use it are considered, and increasingly labeled as, not secure. Browsers are starting to enforce that many new and existing web features must only be used from an secure context (<a href=\"https:\/\/www.chromium.org\/Home\/chromium-security\/deprecating-powerful-features-on-insecure-origins\">Chromium<\/a>, <a href=\"https:\/\/blog.mozilla.org\/security\/2018\/01\/15\/secure-contexts-everywhere\/\">Mozilla<\/a>). GDPR requires the use of HTTPS to protect user privacy. While using HTTPS in production is critical, using HTTPS during development can also help prevent related issues before deployment, like insecure links.<\/p>\n<h5>On by default<\/h5>\n<p>To facilitate secure website development, we are enabling HTTPS in ASP.NET Core 2.1 by default. Starting in 2.1, in addition to listing on http:\/\/localhost:5000, Kestrel will listen on https:\/\/localhost:5001 when a local development certificate is present. A suitable certificate will be created when the .NET Core SDK is installed or can be manually setup using the new &#8216;dev-certs&#8217; tool. We will also update our project templates to run on HTTPS by default and include HTTPS redirection and HSTS support.<\/p>\n<h5>HTTPS redirection and enforcement<\/h5>\n<p>Web apps typically need to listen on both HTTP and HTTPS, but then redirect all HTTP traffic to HTTPS. ASP.NET Core 2.0 has URL rewrite middleware that can be used for this purpose, but it could be tricky to configure correctly. In 2.1 we are introducing specialized HTTPS redirection middleware that intelligently redirects based on the presence of configuration or bound server ports.<\/p>\n<p>Use of HTTPS can be further enforced using HTTP Strict Transport Security Protocol (HSTS), which instructs browsers to always access the site via HTTPS. ASP.NET Core 2.1 adds HSTS middleware that supports options for max age, subdomains, and the HSTS preload list.<\/p>\n<h5>Configuration for production<\/h5>\n<p>In production, HTTPS must be explicitly configured. In 2.1 we are introducing default configuration schema for configuring HTTPS for Kestrel that is simple and straightforward. You can configure multiple endpoints including the URLs and the certificate to use for HTTPS either from a file on disk or from a certificate store:<\/p>\n<h5>Virtual authentication schemes<\/h5>\n<p>We\u2019re adding something tentatively called \u201cVirtual Schemes\u201d to address two main scenarios:<\/p>\n<ol>\n<li>Making it easier to mix authentication schemes, like bearer tokens and cookie authentication in the same app (sample). Virtual schemes allow you to configure a dynamic authentication scheme that will use bearer authentication only for requests starting with \/api, and cookie authentication otherwise\n<\/li>\n<li>Compose (mix\/match) different authentication verbs (Challenge\/SignIn\/SignOut\/Authenticate) across different handlers. For example, combining OAuth + Cookies, where you would have Challenge = OAuth, and everything else handled by cookies.<\/li>\n<\/ol>\n<h3 id=\"identity\">Identity<\/h3>\n<h4>Identity as a library<\/h4>\n<p>ASP.NET Core Identity gives you a framework for setting up authentication and identity concerns for your site, including user registration, managing passwords, two-factor authentication, social logins and much more. However, setting up a site to use ASP.NET Core Identity requires quite a bit of code. While project templates help with generating this code, they don\u2019t help with adding identity to an existing application and the code can\u2019t easily be updated.<\/p>\n<p>For 2.1 we will provide a default identity UI implementation as a library. You can add the default identity UI to your application by installing a NuGet package and then enable it in your Startup class:\n<\/p>\n<h4>Identity scaffolder<\/h4>\n<p>If you want all the identity code to be in your application so that you can change it however you want, you can use the new identity scaffolder to add the identity code to your application. All the scaffolded identity code is generated in an identity specific area folder so that it remains nicely separated from your application code.<\/p>\n<h3 id=\"options\">Options improvements<\/h3>\n<p>To configure options with the help of configured services, you can today implement <code>IConfigureOptions&lt;T&gt;<\/code>. In 2.1 we\u2019re adding convenience overloads to the <code>Configure<\/code> method that allow you to configure options using services without having to implement a separate class:<\/p>\n<p>Also, the new <code>ConfigureOptions&lt;TSetup&gt;<\/code> method lets you register a single class that configures multiple options (by implementing <code>IConfigureOptions&lt;T&gt;<\/code> multiple times):<\/p>\n<h3 id=\"httpclientfactory\">HttpClientFactory<\/h3>\n<p>The new <code>HttpClientFactory<\/code> type can be registered and used to configure and consume instances of <code>HttpClient<\/code> in your application. It provides several benefits:<\/p>\n<ol>\n<li>Provide a central location for naming and configuring logical instances of <code>HttpClient<\/code>. For example, you may configure a \u201cgithub\u201d client that is pre-configured to access GitHub and a default client for other purposes.<\/li>\n<li>Codify the concept of outgoing middleware via delegating handlers in <code>HttpClient<\/code> and implementing Polly based middleware to take advantage of that.<\/li>\n<li>Manage the lifetime of <code>HttpClientMessageHandlers<\/code> to avoid common problems that can be hit when managing <code>HttpClient<\/code> lifetimes yourself.<\/li>\n<\/ol>\n<p><code>HttpClient<\/code> already has the concept of delegating handlers that could be linked together for outgoing HTTP requests. The factory will make registering of these per named client more intuitive as well as implement a Polly handler that allows Polly policies to be used for Retry, CircuitBreakers, etc. Other \u201cmiddleware\u201d could also be implemented in the future but we don\u2019t yet know when that will be.<\/p>\n<p>In this first example we will configure two logical <code>HttpClient<\/code> configurations, a default one with no name and a named \u201cgithub\u201d client.<\/p>\n<p>Registration in Startup.cs:\n<\/p>\n<p>Consumption in a controller:\n<\/p>\n<p>In addition to using strings to differentiate configurations of <code>HttpClient<\/code>, you can also leverage the DI system using what we are calling a typed client:<\/p>\n<p>A class called <code>GitHubService<\/code>:\n<\/p>\n<p>This type can have behavior and completely encapsulate <code>HttpClient<\/code> access if you wish, or just be used as a strongly typed way of naming an <code>HttpClient<\/code> as shown here.<\/p>\n<p>Registration in Startup.cs:<\/p>\n<p>NOTE: The Polly section of this code sample should be considered pseudocode at best. We haven\u2019t built this yet and as such are not sure of the final shape of the API.\n<\/p>\n<p>Consumption in a Razor Page:\n<\/p>\n<h3 id=\"kestrel\">Kestrel<\/h3>\n<h4>Transport Extensibility<\/h4>\n<p>The current implementation of the underlying libuv connection semantics has been decoupled from the rest of Kestrel and abstracted away into a new Transport abstraction. While we continue to ship with libuv as the default transport, we are also adding support for a new transport based on the socket types included in .NET.<\/p>\n<h4>Socket Transport<\/h4>\n<p>We are continuing to invest in a new socket transport for Kestrel as we believe it has the potential to be more performant than the existing libuv transport. While we aren&#8217;t quite there yet, you can still easily switch to the new socket transport and try it out today.\n<\/p>\n<h4>Default configuration<\/h4>\n<p>We are adding support to Kestrel for configuring endpoints and HTTPS settings (see\u00a0<a href=\"#security\">HTTPS: Configuration for production<\/a>)<\/p>\n<h3 id=\"ancm\">ASP.NET Core Module<\/h3>\n<p>The ASP.NET Core Module (ANCM) is a global IIS module for IIS that acts as a reverse-proxy from IIS to your Kestrel backend.<\/p>\n<h4>Version agility<\/h4>\n<p>Since ANCM is a global singleton, it can\u2019t version or ship with the same agility as the rest of the ASP.NET Core. In 2.1, we&#8217;ve refactored ANCM into two pieces: the shim and the request handler. The shim will continue to be installed as a global singleton, but the request handler will ship as part of the new Microsoft.AspNetCore.Server.IIS package which can be referenced directly by your application. This will allow you to use different versions of ANCM with different app deployments.<\/p>\n<h4>In-process hosting<\/h4>\n<p>In 2.1, we&#8217;re adding a new in-process mode to ANCM for .NET Core based apps where the runtime and your app are both loaded inside the IIS worker process (w3wp.exe). This removes the performance penalty of proxying requests over the loopback adapter. Our preliminary tests show performance improvements of around ~4.4x compared to running out-of-process. Configuring your app to use to use the in-process model can be done using <code>web.config<\/code>, and will be eventually be the default for new applications targeting 2.1:\n<\/p>\n<p>Alternatively, you can set a project property in your project file:\n<\/p>\n<h3 id=\"app\">New Microsoft.AspNetCore.App package<\/h3>\n<p>ASP.NET Core 2.1 will introduce a new meta-package for use by applications: Microsoft.AspNetCore.App. The new meta-package differs from the existing meta-package in that it reduces the number of dependencies of packages not owned or supported by the ASP.NET or .NET teams to just those deemed necessary to ensure the major framework features function. We will update project templates to use the new meta-package. The existing Microsoft.AspNetCore.All meta-package will continue to be made available throughout the 2.x lifecycle. For additional details see https:\/\/github.com\/aspnet\/Announcements\/issues\/287.<\/p>\n<h3>In conclusion<\/h3>\n<p>We hope you are as excited about these features and improvements as we are! Of course, it is still early in the release and these plans are subject to change, but you can follow along with the latest status of these features by <a href=\"https:\/\/github.com\/aspnet\/home\">tracking the action on GitHub<\/a>. Major updates and changes will be posted on the <a href=\"https:\/\/github.com\/aspnet\/announcements\">Announcements<\/a> repo. You can also get live updates and participate in the conversation by watching the weekly ASP.NET Community Standup at https:\/\/live.asp.net. You can also read about the roadmaps for .NET Core 2.1 and EF Core 2.0 on the <a href=\"https:\/\/blogs.msdn.microsoft.com\/dotnet\/\">.NET team blog<\/a>. Your feedback is welcome and appreciated!<\/p>\n","protected":false},"excerpt":{"rendered":"<p>Five months ago, we shipped ASP.NET Core 2.0 as a foundational release for our high performance, cross-platform web framework for .NET and .NET Core. Since then we have been hard at work to deliver the next wave of features in ASP.NET Core 2.1. Below is an outline of the features and improvements that are planned [&hellip;]<\/p>\n","protected":false},"author":417,"featured_media":21374,"comment_status":"open","ping_status":"closed","sticky":false,"template":"","format":"standard","meta":{"_acf_changed":false,"footnotes":""},"categories":[197,7509],"tags":[119],"class_list":["post-11305","post","type-post","status-publish","format-standard","has-post-thumbnail","hentry","category-aspnet","category-aspnetcore","tag-roadmap"],"acf":[],"blog_post_summary":"<p>Five months ago, we shipped ASP.NET Core 2.0 as a foundational release for our high performance, cross-platform web framework for .NET and .NET Core. Since then we have been hard at work to deliver the next wave of features in ASP.NET Core 2.1. Below is an outline of the features and improvements that are planned [&hellip;]<\/p>\n","_links":{"self":[{"href":"https:\/\/devblogs.microsoft.com\/dotnet\/wp-json\/wp\/v2\/posts\/11305","targetHints":{"allow":["GET"]}}],"collection":[{"href":"https:\/\/devblogs.microsoft.com\/dotnet\/wp-json\/wp\/v2\/posts"}],"about":[{"href":"https:\/\/devblogs.microsoft.com\/dotnet\/wp-json\/wp\/v2\/types\/post"}],"author":[{"embeddable":true,"href":"https:\/\/devblogs.microsoft.com\/dotnet\/wp-json\/wp\/v2\/users\/417"}],"replies":[{"embeddable":true,"href":"https:\/\/devblogs.microsoft.com\/dotnet\/wp-json\/wp\/v2\/comments?post=11305"}],"version-history":[{"count":0,"href":"https:\/\/devblogs.microsoft.com\/dotnet\/wp-json\/wp\/v2\/posts\/11305\/revisions"}],"wp:featuredmedia":[{"embeddable":true,"href":"https:\/\/devblogs.microsoft.com\/dotnet\/wp-json\/wp\/v2\/media\/21374"}],"wp:attachment":[{"href":"https:\/\/devblogs.microsoft.com\/dotnet\/wp-json\/wp\/v2\/media?parent=11305"}],"wp:term":[{"taxonomy":"category","embeddable":true,"href":"https:\/\/devblogs.microsoft.com\/dotnet\/wp-json\/wp\/v2\/categories?post=11305"},{"taxonomy":"post_tag","embeddable":true,"href":"https:\/\/devblogs.microsoft.com\/dotnet\/wp-json\/wp\/v2\/tags?post=11305"}],"curies":[{"name":"wp","href":"https:\/\/api.w.org\/{rel}","templated":true}]}}