In the article we are going to look at the importance of a good version control system, and why it is crucial when it comes to API versioning.

It is essential that we deploy a Web API version control from an early stage in our project. Versioning will ensure that the project is built on a solid base and that a standard is maintained. A good version control system will enable us to collaborate and scale in a managed way, and as such will provide our customers with a more straightforward progression through our upgrades.

The first point to note we should always version our Web API, while at the same time keeping as much of the same URI as possible, with the possibility of newer versions having a different URI and a clear upgrade path.

What is versioning?

Versioning is a thoughtful application of changes to a system that is already in production.

There are two types of versioning, they are:

• Versioning Data – changing the way we lay out our data structures, name things and so on
• Version SOAP Endpoints – adding or removing functionality, such as functions that can be called or changing parameters that can be called on those endpoints

Plan Versioning

How do we handle versioning?  We are producing a plan for the first release, and we need to do the following:

• At the start
  • Pick a version-able identifier
  • pick a versioning pattern
• Version-able identifiers
  • XML Data: XML Namespace
  • Things that listen at URL’s: URL Path
• Numbering Pattern
  • https://yoururl.co.uk/[service name]/major.[minor].[build[
  • Each number increases monotonically: 1,2,3,4, …., 9, 10, 11
• Date Pattern
  • https://yoururl.co.uk/[service name]/[yyyy]/[mm]/[dd]
  • https://yoururl.co.uk/[service name]/[yyyy].[mm].[dd]

The only time we ever need to version is when we change the contract with the client, we can change the contract in one of three ways:

• Data
  • Add a new type
  • Removing a type
  • Change fields
  • Required fields
• SOAP
  • Add/remove methods
  • Change parameter names
  • In session: change the set of initiating/termination actions
• REST
  • Change URI structure
  • Add methods

Versioning Data

There are times when you need to version the data:

• Reasons to version data
  • Name chooser picked terrible names (aka renames)
  • Adding/removing fields
• Things to handle upon versioning data
  • Co-existing old/new clients
• Reason not to version data
  • Re-ordering for aesthetic reasons

New Members

• If a new member is required, define sensible default
  • Caveat: if no sensible default exists, you have a severe bug in a previous version
  • If you think you have no reasonable default and customers won’t change, you will suddenly find a sensible default
• Place at the end
  • Some clients may be ordinal dependent, not name
  • Use DataMember.Order property
• Or inherit Data Transformation Object if new item breaks old clients

Versioning SOAP Endpoints

• Reasons to version endpoints
  • Name chooser picked terrible names (aka renames)
  • Adding methods
  • Removing methods
  • Updating method parameters (new version of old type)
  • Adding terminating functions (might already exist)
• Things to handle upon versioning endpoints
  • Update old to call out to controller properly
• Reasons not to version endpoint
  • Re-ordering for esthetic reasons (don’t do this!)

Handle Versioning

• Keep services light
• Keep details in separate class
• Use MVC type pattern
  • DTO is Model
  • Service is View
  • “Separate class” is Controller
• Benefits
  • Minimize code churn in services
  • Keep logic mapping DTO to Business in one place

Key Points

• Keep service code clean, simple.
• Think of service as a machine UI to the real object model.
• Let internal logic worry about mapping DTO to the business objects.
• Handle upgrade in one place, away from service.

Versioning REST Endpoints

• Reasons to version REST endpoints
  • Name chooser picked terrible names
  • Paths don’t make sense
  • Updating data types, parameters (new version of old model)
• Things to handle upon versioning endpoints
  • Update old to call out to controller properly
• Reasons not to version endpoint
  • Supporting more of Uniform Interface (GET | HEAD, PUT, POST, DELETE)

Where to version?

• New set of services in new directory
  • Pros: clean separation, small files, easy to read, allows for more natural deletion later
  • Cons: not necessary, moves logic to new file
• Keep everything in one file, add new UriTemplates
  • Pros: All URLs in one place, easy to see what uses code, can see evolution in one place
  • Cons: Likely to clutter code, increase maintenance burden over time

Support Plans for Versioning

• Need an SLA between service and consumers
• Need to define
  • How long a consumer can depend on a version
  • What constitutes end of life for a version
• Need to prepare for
  • Extensions to end of life
  • Presence of older clients
  • Work with client to update to latest

Assets to Create to Assist/Reduce Burden

• Documentation on wire-level formats
  • XSD, HTML documents, sample code
• SDKs in client languages
  • Java, Ruby, PHP, Python, .NET
  • Can ease migration.
    • Client uses new library, works till clean compile
    • Versioning issue becomes deployment issue
• Support staff
  • Dedicate staff to help support clients who are migrating code.

Summary

• Versioning: The retrospective application of changes to a system.
• Plan ahead
  • URL structure, version names, use MVC pattern
• Changes hit in three, related areas: Data, SOAP Methods, REST
• Manage changes
• Create new endpoints for new data types
• Use Data Transformation Objects
• Keep logic to translate between Data Transformation Objects and business in one place

References

Versioning Strategies by Microsoft

Best Practices: Data Contract Versioning

ASP.NET Core RESTful Web API versioning made easy by Scott Hanselman