Versioning WebApi and documenting version with Swagger

Versioning in WebApi

Note: This post draws alot of points from – but is more about implementation and documentation through swagger.
So please go read Troy’s post and then come back :).
There are a couple of ways of versioning a restful api
among them are:
1. Url versioning e.g. GET
2. Request-Header e.g. GET — Header: api-version: 1
There are pros and cons in both regards, Troy gets around them quite nicely.
Time to code!

Url Versioning

Easy – simply use either the RoutePrefix- or RouteAttribute

Read more about the Routing-Attribute here


Drawing from Troy’s post
We create a new attribute which uses a custom routing constraint

** Usage **

Effectively matching routes based on the “api-version” header.


When using swashbuckle (swagger implementation for .Net).
It knows about the default Route- and RoutePrefixAttribute, so Url Versioning is taken care of, out of the box.
But Header versioning is not.
Fortunately, it’s quite easy to implement an OperationFilter that adds the header as a parameter to the endpoints in question.
This implementation uses a list of versions and the endpoints relativepaths to know when to add the parameter and when not to.

How would you implement the OperationFilter?

Documenting roles with swashbuckle

How to document attribute usage with swagger

You could basically document any attribute you have decorated your actions with, but this will focus mainly on documenting the role part of the Authorize attribute.
When using roles based authentication I like to document the roles in my swagger spec, this gives a nice indication, to the consumer, of which roles are required for different endpoints.
Here I have a basic Authorize attribute with a required role of “Admin”.

As with most other things swashbuckle related, we need to create an IOperationFilter

And that is it, you have now auto documented every role required across your API.
The swagger docs will look like the following.

Throttling actions in WebApi using AttributeFilter

I recently had to come up with a solution to throttle an action in an API i’ve written.
First thing I did was to see what others had used (No reason to invent the wheel right?).
I came across this stackoverflow answer – which is basically what I will use in this blog post (mostly for a reminder to myself I guess).
Full credits go to Jarrod Dixon

The Attribute

The Annotation

Since it’s an attribute, we just annote it to an action
The attribute takes a unique name, amount of seconds and the message to return.
If the action is run more often than allowed, the action will return 409 - conflict