Skip to main content

Versioning an API

Strategies

1. URI

Each time we change the version, the clients will have to change the URL.

2. Via Query String

3. Via Headers

The client needs to have a developer who knows how to deal with headers, more sophisticated approach. Also we need to create our own custom header.

4.  VIA ACCEPT HEADERS

Add  the nuget package -- Microsoft.AspNetCore.Mvc.Versioning

[ApiVersion("1.0")]
[ApiVersion("1.1")]
[ApiVersion("2.0")]
public class WeatherForecastController : ControllerBase

Add this to the controller to let the user know what version it supports.

To the actions Specify these.
        [HttpGet("sample")]
        [MapToApiVersion("1.0")]
        public IActionResult Getv1(string id) => Ok("Version 1");

        [HttpGet("sample")]
        [MapToApiVersion("1.1")]
        public IActionResult Getv2() => Ok("Version 1.1");

        [HttpGet("sample")]
        [MapToApiVersion("2.0")]
        public IActionResult GetV2() => Ok("Version 2");

When we call the API a string "Version 2 " is returned because we have set the Default Version to 2.0. This is still using QueryString to specify the version. If we try to request another version we will have to specify it in the query string.

https://localhost:44378/api/values/sample?api-version=1.0

Specify Versioning using a header

 services.AddApiVersioning(op=> {

                //Specify the default version for the API. Default routes that match this version will
                // be invoked
                op.DefaultApiVersion = new ApiVersion(2,0);
                //If default version is not specified in the query string then 
                // we assume the above mentioned version as default.
                op.AssumeDefaultVersionWhenUnspecified = true;

                //Tell the user what all version that Api supports, will be added as a header.
                op.ReportApiVersions = true;


                //Add this to specify that the version will be passed as a header with
                //the following key
                op.ApiVersionReader = new HeaderApiVersionReader("X-Version");
                         // new QueryStringApiVersionReader();
            });





































Comments

Popular posts from this blog

Az-500 NSG and ASG

Application security groups Application security groups enable you to configure network security as a natural extension of an application's structure, allowing you to group virtual machines and define network security policies based on those groups. You can reuse your security policy at scale without manual maintenance of explicit IP addresses. The platform handles the complexity of explicit IP addresses and multiple rule sets, allowing you to focus on your business logic. To better understand application security groups, consider the following example: In the previous picture,  NIC1  and  NIC2  are members of the  AsgWeb  application security group.  NIC3  is a member of the  AsgLogic  application security group.  NIC4  is a member of the  AsgDb  application security group. Though each network interface in this example is a member of only one network security group, a network interface can be a member of multiple app...

App Role assignment to service principal --

 Using Ms Graph Rest API's Permissions One of the following permissions is required to call this API. To learn more, including how to choose permissions, see  Permissions . Permission type Permissions (from least to most privileged) Delegated (work or school account) AppRoleAssignment.ReadWrite.All and Application.Read.All, AppRoleAssignment.ReadWrite.All and Directory.Read.All, Application.ReadWrite.All, Directory.ReadWrite.All Delegated (personal Microsoft account) Not supported. Application AppRoleAssignment.ReadWrite.All and Application.Read.All, AppRoleAssignment.ReadWrite.All and Directory.Read.All, Application.ReadWrite.All, Directory.ReadWrite.All Create 2 app registrations. App role owner will contain the app role that will be assigned to a service principal. The  reader role in approleowner will be added to the approlesubscriber Setup postman to use the Oauth auth flow to get a token for MS Graph. ClientId:   Application (client) ID for approlesubscrib...

ASp.net core 3.1 identity

It is just an extension to cookie authentication. We get a UI, Tables, helper classes, two factor authentication etc. Even EF and its database constructs. So instead of writing code for all of this we can just use these in built features. Extending Default Identity Classes Add a class that inherits from    public class AppUser : IdentityUser     {         public string Behavior { get; set; }     } Also change the user type in login partial.cs under shared folder Then add migrations and update db using migrations. We can customize further.  services.AddDefaultIdentity<AppUser>(options =>              {                 options.SignIn.RequireConfirmedAccount = true;                 options.Password.RequireDigit = false;           ...