This would allow us to deploy changes to the web api without closing the trees.
I'm going to base this implementation on django-oauth-toolkit, which the is recommended package to do oauth authentication with django-rest-framework http://www.django-rest-framework.org/api-guide/authentication/#django-oauth-toolkit
Oops wrong bug
Created attachment 8637342 [details] [review] PR 800
Assignee: nobody → mdoglio
Status: NEW → ASSIGNED
Attachment #8637342 - Flags: review?(emorley)
Comment on attachment 8637342 [details] [review] PR 800 Awesome, thank you! :-)
Attachment #8637342 - Flags: review?(emorley) → review+
Meant to say, if we ever use anything other than the header based versioning, we'll need to start passing the request argument in reverse() calls, but for now this is fine :-)
Commit pushed to master at https://github.com/mozilla/treeherder https://github.com/mozilla/treeherder/commit/e3d4c3162ddefd07679b43e6db7a5952d92277e2 Bug 1145720 - Setup api versioning
Status: ASSIGNED → RESOLVED
Last Resolved: 3 years ago
Resolution: --- → FIXED
Once the nodejs client also requests a specific version in the Accepts header, and all submitters have updated to a newer python/node client, do we want to enforce that an API version is specified is the content-type is not text/html? (ie not mandatory if the API is browsed to in the browser, but required otherwise) Relatedly, should we support specifying the version in the URL for the browser use-case, or are we happy that the new headers features in the Firefox developer tools make this redundant? I'm leaning towards the latter.
You need to log in before you can comment on or make changes to this bug.