Version API from beginning

[bhgrant8]

We may have a few iterations of our api where other Hack Oregon teams are using endpoints, public partners may use others, and our frontend teams may use the service a different way.

To allow iteration and growth, continue to follow a RESTful architecture, but not force deprecation on our users, we should plan for versioning from the beginning. (See #7 in https://hackernoon.com/restful-api-designing-guidelines-the-best-practices-60e1d954e7c9)

URL versioning seems to have advantages over header based, but lets talk about best practice

[bhgrant8]

Good article on versioning in Django Rest Framework to consider: https://gearheart.io/blog/api-versioning-with-django-rest-framework/

[znmeb]

The only two APIs I use heavily use URL versioning. I think Twitter does too. But old versions do need deprecation and eventual removal, right?

[BrianHGrant]

Yes and this process is far easier when stating a version of the api will be deprecated on a certain date.

[kiniadit]

I'm thinking AcceptHeaderVersioning would be the way to go. DRF supports this and looks relatively easy to implement.

Though I'm stuck on figuring out how to incorporate custom content-types with Django (e.g. Accept: application/vnd.company.myapp.customer-v3+json)

Best Practices for API versioning

[bhgrant8]

I believe header versioning has been implemented? Are you still having issues with the custom content-types?

[bhgrant8]

implemented in pr #38