session - 你能帮我理解这一点吗？ "Common REST Mistakes: Sessions are irrelevant"

Question

免责声明:我是 REST 思想流派的新手，我正在努力理解它。

所以，我正在阅读此页，Common REST Mistakes ，我发现我对与 session 无关的部分感到完全困惑。页面内容如下:

There should be no need for a client to "login" or "start a connection." HTTP authentication is done automatically on every message. Client applications are consumers of resources, not services. Therefore there is nothing to log in to! Let's say that you are booking a flight on a REST web service. You don't create a new "session" connection to the service. Rather you ask the "itinerary creator object" to create you a new itinerary. You can start filling in the blanks but then get some totally different component elsewhere on the web to fill in some other blanks. There is no session so there is no problem of migrating session state between clients. There is also no issue of "session affinity" in the server (though there are still load balancing issues to continue).

好吧，我知道 HTTP 身份验证是在每条消息上自动完成的 - 但如何实现呢？用户名/密码是否随每个请求一起发送？这不是增加了攻击面吗？我觉得我遗漏了拼图的一部分。

拥有一个接受 GET 请求的 REST 服务(例如 /session)会不会很糟糕，您可以在其中传递用户名/密码作为请求的一部分，并返回如果身份验证成功， session token 可以与后续请求一起传递吗？从 REST 的角度来看，这有意义吗？还是没有捕获要点？

Answer 1

为了实现 RESTful，每个 HTTP 请求本身都应该携带足够的信息，以便其接收者对其进行处理，从而与 HTTP 的无状态性质完全协调。

Okay, I get that HTTP authentication is done automatically on every message - but how?

是的，用户名和密码会随每个请求一起发送。常见的方法是基本访问身份验证和摘要访问身份验证。是的，窃听者可以捕获用户的凭据。因此，可以使用传输层安全性 (TLS) 对发送和接收的所有数据进行加密。

Would it be bad to have a REST service, say, /session, that accepts a GET request, where you'd pass in a username/password as part of the request, and returns a session token if the authentication was successful, that could be then passed along with subsequent requests? Does that make sense from a REST point of view, or is that missing the point?

这不是RESTful，因为它带有状态，但它很常见，因为它为用户带来了便利；用户不必每次都登录。

您在“ session token ”中描述的内容通常称为登录 cookie。例如，如果您尝试登录 Yahoo!帐户上有一个复选框，上面写着“让我保持登录状态 2 周”。这本质上是说(用你的话来说)“如果我成功登录，请将我的 session token 保留两周”。 Web 浏览器将在您要求其为您发出的每个 HTTP 请求中发送此类登录 cookie(可能还有其他)。