javascript - 对存储在数据库中的会话数据的混淆违反了 REST 原则

Question

我正在写一份关于我设计的应用程序的报告，其中包括我认为的后端的 REST API。

应用程序授权用户从数据库请求资源的方式是使用会话 cookie。我知道关于会话 cookie 服务器端是否违反 REST 存在很多争论，但我没有找到任何具体说明，说明我使用它们的方式违反了 REST 规则。

我正在使用带有包的节点Express框架。express-session创建和存储 cookie 的方式是通过一个将会话数据保存到我的mongodb实例的中间件，connect-mongodb-session如下所示：

应用程序.js

    // app.js imports start
    const mongoose = require("mongoose");
    const session = require("express-session");
    const config = require("config");
    const MongoDBStore = require("connect-mongodb-session")
    // app.js imports end

    const mdbStore = new MongoDBStore({
        uri: config.get("mongoURI"),
        mongooseConnection: mongoose.connection,
        collection: "sessions",
        ttl: config.get("sessionLife") / 1000,
    });

    // Session middleware
    app.use(
        session({
            name: config.get("sessionName"),
            genid: function () {
                return uuid.v4();
            },
            secret: config.get("sessionKey"),
            resave: false,
            saveUninitialized: false,
            cookie: {
                sameSite: true,
                httpOnly: true,
                maxAge: config.get("sessionLife"),
            },
            store: mdbStore,
        })
    );

This means that when a client request comes in, the client's authorisation data will be available via req.session, but that data is coming from my database, not being stored on the server anywhere.

So ultimately this means that my server doesn't store any user data directly, but has a dependency on the state of a session cookie stored in the database. Does this mean the API is not RESTful?

I have read through this SO article and only found a small mention of cookies stored in a database Do sessions really violate RESTfulness? but would still really appreciate any comments/clarifications/criticisms anyone has. Thanks

标签： javascriptnode.jsmongodbrestexpress

Answer 1

it is based on the nature of the front end

if you use mobile application deployed in a public store where anyone downloads it and auto register using social ID, then your technology is not good

Usually for a enterprise mobile application, the session Data should be encrypted and sent back and forth in the request response and maintained in the mobile code

if this is simply a web page and the REST also available in the same sever where the HTML is deployed then session can be stored in DB

If the REST is separated in another computer and you invoke it from the front end server side code via internal ip/host address which is not exposed to public, then your logic is not good

front end server side code - means you can have a dedicated server which responsible for react js execution which does not contains the database access code - only AJAX service it will have which is obviously REST, there can be another server which will again receive another REST call which will talk to another computer where MySQL or Oracle is installed

means 1 web server 1 app server and 1 database server - like real world enterprise applications

if your DB is not configured in the same computer then storing session in DB is not a good idea, create a cache DB server like redis or couchbase in the first computer and store the session there, leave the business DB alone separated from your UI logic and needs