Development with a Dot

Introduction To get the new year started, another post on my ASP.NET Core Pitfalls series! This time, it's related to APIs, and how the [Consumes] attribute is interpreted. The Problem The Content-Typ e header and optional charset parameter are part of the web standard and used to tell the server handler what type of content the client will send. The charset part is optional, and the default is " ascii "; for example, if we wish to set it as UTF-8 , we should sent: Content-Type: application/json;charset=utf-8 Now, charset is optional, and does not really change what the content type is, just the character set of the text of the payload. In ASP.NET Core, it can be used to route the request to different endpoints: for example, two action methods for the same action can consume different content types. There is an attribute,  [Consumes] , which can be used in ASP.NET Core MVC to restrict the content types that are accepted by a given action method. [HttpGet("Get...

This was ported from my original blog post here . Introduction When you have an existing deployed REST API that you want to change, you generally need to be very careful. Why would you want to change it? There can be a number of reasons: Changes to the request contract (adding, removing or modifying request parameters) Changes to the response contract (same as above) Changes to the behaviour of the existing actions (they now do something slightly different) Changes to the HTTP methods that the existing actions accept (not so common) Changes to the HTTP return status codes … In a controlled environment, you can change at the same time the server and the client implementations, which means that you can update your clients accordingly, but, unfortunately, this is not always the case. Enter versioning! With versioned APIs, you can have multiple versions of your API, one that the legacy clients will still recognise and be able to talk to, and possibly one or more that are more suitable for ...