Edition 0 Updated to asp. Net core 0

Implementing versioning in ASP.NET Web APIs 
As business requirements change, new collections of resources may be added, the relationships 
between resources might change, and the structure of the data in resources might be amended. 
Updating a Web API to handle new requirements is a relatively straightforward process, but you must 
consider the effects that such changes will have on client applications consuming the Web API. 
Although the developer designing and implementing a Web API has full control over that API, the 
developer does not have the same degree of control over client applications that might be built by 
third-party organizations operating remotely. 
Versioning enables a Web API to indicate the features and resources that it exposes. A client 
application can then submit requests to a specific version of a feature or resource. There are several 
approaches to implement versioning: 
•
URI versioning 
•
Query string versioning 
•
Header versioning 
Query string and URI versioning are the simplest to implement. Header versioning is a good 
approach. However, header versioning is not as explicit and straightforward as URI versioning. 
Because URL versioning is the simplest and most explicit, the eShopOnContainers sample application 
uses URI versioning. 

---

111 
CHAPTER 5 | Designing and Developing Multi-Container and Microservice-Based .NET Applications 
With URI versioning, as in the eShopOnContainers sample application, each time you modify the Web 
API or change the schema of resources, you add a version number to the URI for each resource. 
Existing URIs should continue to operate as before, returning resources that conform to the schema 
that matches the requested version. 
As shown in the following code example, the version can be set by using the Route attribute in the 
Web API controller, which makes the version explicit in the URI (v1 in this case). 
[
Route
(
"api/v1/[controller]"
)]