问题描述
我正在为我正在创建的 Web 应用程序编写 REST/RPC API.据我所知，REST 背后的核心思想之一似乎是不维护任何状态.也就是说，我发现自己在做一些事情，比如在服务器端将会话标记为已通过身份验证，这感觉就像是在保存状态.我应该把这个练习走多远?我应该在哪里划线?还有其他一些东西可以非常方便地保存为会话变量的一部分，但我想知道我怎么知道什么时候不应该或不应该这样做.
I'm coding up a REST/RPC API for a web app that I'm creating. From what I've learned it seems like one of the core ideas behind REST is to not maintain any state. That said I find myself doing things like marking a session as authenticated on the server side of things and this feels like saving state. How far should I take this practice? Where should I draw the line? There are other things that would be really convenient to save as part of the session's variables but I'm wondering how do I know when I shouldn't or shouldn't do this.
我希望这是提出这个问题的合适场所.我争论过要不要把它贴在程序员那里，但我觉得这个更合适.
I hope this is the right venue to ask this question. I debated on whether or not to post it in programmers but this just felt more appropriate.
更新:
有人告诉我，使用票务系统比使用会话变量来维护诸如身份验证信息之类的内容要好.有人可以包括并回答对这种票务系统如何工作有高度描述的吗?
I'm told that using a ticketing system is better than using session variables to maintain things like auth information. Could someone include and answer that has a very highly description of how such a ticketing system would work?
推荐答案
您是对的 - REST 调用在理想情况下是无状态的，并且在会话变量中存储某些内容并将其用于 REST 调用是令人厌恶的.例如，您无法保证 RESTful 客户端甚至可以发送会话变量所需的 cookie 信息.
You are correct - REST calls are ideally stateless, and storing something in a session variable, and using that for the REST call, is anathema. You can't, for instance, guarantee that a RESTful client can even send the cookie information necessary for the session variables.
如果您需要身份验证，那么您应该让 REST 调用返回类似于票证的内容，然后 REST 调用者会将该票证作为另一个调用的一部分发送.
If you need authentication, then you should have REST calls that return something like a ticket, then the REST caller would send that ticket as part of another call.
更新对于票务系统，您通常希望使用相同的身份验证或类似的身份验证系统.例如，如果您需要用户名和密码，您可能希望票证请求 POST.票证是在后续调用中传递的 GUID.服务器上的票证可以存储在会话中，也可以存储在数据库中(我通常有一个 TICKETS 表，其中包含到期日期之类的内容).
UPDATEFor a ticketing system, you generally want to use the same auth or similar auth system. For instance, if you require a user name and password, you might want the ticket request to POST that. A ticket is a GUID that is passed on subsequent calls. The ticket on the server can be stored in session, or in a DB (I typically have a TICKETS table, with things like expiration dates).
$result = file_get_contents('http://site.com?action=auth&user=matt&password=pass');
// parse $result XML for ticket or auth error
// subsequent calls...
$result = file_get_contents('http://site.com?action=getSomething&ticket=" . $ticket);
QuickBase 以这种方式工作 - 您发送带有用户名、密码和 api 应用程序令牌的 API_Auth 操作，并获得一张票作为回报.然后您在后续调用中传递您的 api 应用令牌和票证 - GET 请求和 POST 发送.
QuickBase works this way - you send an API_Auth action with a username, password and api app token, and get a ticket in return. Then you pass your api app token and the ticket on subsequent calls - both GET requests and POST sends.
这篇关于我可以在 Web 应用程序的会话变量中保存多少状态?的文章就介绍到这了，希望我们推荐的答案对大家有所帮助，也希望大家多多支持！