Q:

How do i setup routing for my API and my websocket

I'm making a django/react webapplication and would like to be able to use both a rest api and a websocket. 
to set the stage a bit:
I have a authentication app and a project app and some other apps. i want my authentication app to use the rest framework to process login/register requests, after this i want to be able to use the project apps websocket in order to keep things flowing smoothly. i have however no idea how to set this up.
Backend (main project app with settings etc)
Authentication (small app used for authenticating users)(only really needs rest)
Project (bigger app that uses websockets to do stuff as it needs to be updated constantly)
i hope somebody can provide some details or informational links that would point me in the correct direction.or perhaps some code examples
EDIT 1:
So i feel like this needs a bit more clarification.
i'm currently using the django rest framework for the api setup and django channels for the websocket connection. i have managed to get both working seperately, my problem was however, how do i setup the routing to switch between the 2. i believe i have figured it out and if a bit more testing proves this then i will post my routing, settings, urls and other configs as an answer

A:

If you're using django for all of these you should probably use these:

Django rest framework for all the rest related stuff - this handles auth as well 
Django Channels for all your websocket stuff

Both of the above frameworks handle auth out of the box and are pretty easy to setup. DRF in my opinion is way too easy for the rest capabilities it provides. 
I would also spend some thought on whether it is wise to focus all your requests through a web socket. In my experience it's better to use ajax for this as you can collate requests and responses easier as your ajax will wait for a response from the upstream while a websocket will send the request and not wait for a response and the upstream can send a response out of the scope of your initial request. In other words, you need to be able to identify from what request your websocket historically made in order to handle a message sent back by the upstream so that you have context of how to handle the message

