Remove client state

Reading ‘Lightweight Django’ chapter 4 ‘Building a REST API’ It suggest removing ‘django.contrib.sessions.middleware.SessionMiddleware’ as ’ the server will not maintain any client state’ Sounds reasonable don’t you think? As ‘django.contrib.sessions.middleware.SessionMiddleware’ is removed, also middleware and apps dependant on this needs to be removed:

django.contrib.auth.middleware.AuthenticationMiddleware,
django.contrib.auth.middleware.SessionAuthenticationMiddleware, and
django.contrib.messages.middleware.MessageMiddleware

And django.contrib.admin, django.contrib.sessions, django.contrib.messages apps

[spoetnik]

I can add the admin (and thus session, etc) to local settings? My doubt is that local and production vary to much, so “it works on my computer” doesn’t mean anything… Maybe make a ‘backoffice’ settings or something, and add the admin to that?

[agconti]

@spoetnik thanks for your enthusiasm and contribution!

I’m going to close this issue based on this project’s core values:

The idea behind this project is to have the slimmest possible boilerplate while maximizing developer productivity from the get-go. [This] isn’t something that I think the project should support out of the box because it’s a specific use case. While many will find it useful, many others won’t have a need for it.

If this is something that you’d like to maintain yourself – I encourage you to fork the project!

Removing session storage as you’ve outlined adds additional complexity to settings configuration. While some users, like yourself, will want to remove session storage so that there’s no chance they violate RESTful guidelines. Most users will be content to just not use session storage or would like the option to violate RESTful guidelines with session storage when they think its best for their project.

You seem very passionate about this so please fork the project and customize it your own liking!