Split API URLs to second project/settings/wsgi ?

[guettli]

In one small project all web requests were done by humans in the past.

We used a login form and cookie bases sessions.

Now an API gets created and automated processes access these new URLs.

These processes use a different auth backend.

Now I see two possible solutions:


Solution1: Use one project (one settings file, one wsgi endpoint). This means we need to support several auth backends in one settings file.


Solution2: Split human and API calls. This means overhead in the configuration, but has the advantage that you can influence things like
the wsgi-worker queue better. Example: If there are several thousand API requests, the requests for humans don't suffer.


I know that there is not single truth and both solutions have their advantages and disadvantages. But maybe it helps if you write what you
think and what you learned in the past.

Regards,
  Thomas Güttler

[Jason]

What you can do is split the backend into a REST API using http://www.django-rest-framework.org/

Refactor the views to share common logic, and you can have your template renders bound to one view handler and an api call to another.   Configure your urls.py to have a url like /api/{version}/{resource/{id} mapped to an API endpoint.  Since the logic is shared between the different views, you'll get the same results regardless of access method.

The nice part with DRF views is you can customize the permissions and authentications for specific resources.

[guettli]

Yes, this (customize the permissions and authentications for specific resources) sounds very good.

I have other applications where this could be needed. But up to now they don't use DRF.

[Jason]

Sounds like this is a good use case to integrate DRF to solve multiple problems.

[guettli]

Am Mittwoch, 3. Januar 2018 17:40:51 UTC+1 schrieb Jason:

Sounds like this is a good use case to integrate DRF to solve multiple problems.

I am unsure. I would like to have auth solved by the framework. With framework I mean django.

[guettli]

By chance I saw this in the authenticate() docs:

https://docs.djangoproject.com/en/2.0/topics/auth/default/#django.contrib.auth.authenticate

 Changed in Django 1.11: The optional request argument was added.

Maybe this is the reason why DRF did his own auth handling in the past.

Regards,
  Thomas Güttler