Q:

How to implement backend of api with multiple versions

I'm using Django to implement a private rest-like API and I'm unsure of how to handle different versions of the API on the backend.   
Meaning, if I have 2 versions of the API what does my code look like?   Should I have different apps that handle different version?   Should different functions handle different versions?   Or should I just use if statements for when one version differs from another? 
I plan on stating the version in the Header. 
Thanks 

A:

You do not need to version REST APIs.  With REST, versioning happens at runtime either through what one might call 'must-ignore payload extension rules' or through content negotiation. 
'must-ignore payload extension rules' refer to an aspect you build into the design of your messages. ' Must-ignore' means that a piece of software that processes a message of the given format must ignore any unknown syntactical constructs.  This is what we all know from HTML and what makes it possible to insert all sorts of fancy tags into an HTML page without the parser choking. 
'Must-ignore' allows you to evolve the capabilities of your service by adding stuff to what you send already without considering clients that only understand the older versions. 
Content-negotiation refers to the HTTP-built-in mechanism of negotiating the actual representation the server sends to a given client at runtime.  The typical scenario is this: Clients send the Accept header in the request to advertise what they are capable of and servers pick the representation to send back based on these capabilities.  But there are also variations of this theme (see here for details: http://www.w3.org/Protocols/rfc2616/rfc2616-sec12.html ). 
Content negotiation allows for incompatible changes, meaning that I can evolve my service to being able to send incompatible old and new versions and based on the Accept header my service will send the appropriate one. 
Bottom line: with both approaches, your API remains as it is.  No need to do any versioning at the API level - especially not the often suggested (but totally wrong) inclusion of version identifiers in the URIs (remember, you are doing REST here, not SOAP!)