如何强制执行“会话”？在 RESTful Web 服务中使用 RESTlet？
我是 RESTful Web 服务和 RESTlet 的新手。我们只有构建基于 servlet 的 Web 应用程序（JBoss/Apache 上的 Servlet/JSP）的经验。现在，我们正在构建一个基于 RESTlet 的应用程序，其中服务器端 API 将由两种类型的客户端使用 - 使用浏览器的 Web 和通过桌面基于 swing。
我的理解是，根据 REST 概念 a) 服务器无法维护会话以提高可扩展性和其他很少的原因 b）来自客户端的每个请求都应该是独立的
现在，我真的很困惑如何实现这一点。假设我们采用一个简单的购物车应用程序。
步骤1）客户端发送认证请求，服务器进行认证，服务器响应OK。
步骤 2) 客户端发送请求以将商品添加到购物车。服务器响应正常。
步骤 3) 客户端发送另一个请求以将第二件商品添加到购物卡。服务器响应正常。
通常，在正常的 Web 应用程序中，会话是在服务器上的步骤 1 中创建的，从那时起，与该客户端相关的所有请求都会自动与同一个会话关联，并且我们将会话状态（在本例中为购物车）存储在session 对象并使用来自客户端的后续请求检索/更新它。
现在，在上述场景中：
1）如果服务器上没有维护会话，我们如何在步骤 2 和 3 中对客户端进行身份验证和授权？
2）客户是否需要在每个请求中发送一些附加信息？
3) 我们如何在步骤 3 中检索客户特定的购物车？
4) 客户端是否需要在步骤 3 中再次发送步骤 2 中服务器创建/返回的购物车？
显然，这是最简单的用例，因此每个开发 RESTful Web 服务的人都必须设计他们的应用程序来处理这个问题。使用 RESTLet 在 RESTful Web 服务中处理会话管理、身份验证、授权的最佳和最常见的方法是什么？如果我们必须在服务器端维护客户端数据的缓存，那么这与服务器代表我们维护会话有何不同？
提前致谢， 深的
I am new to RESTful web services and RESTlet. WE only have experience building servlet based web applications (Servlet/JSP on JBoss/Apache). Now, we are building a RESTlet based application where the server side API would be used by two types of clients - web using browser and swing based via desktop.
What I understand is that as per REST concepts
a) server can not maintain sessions to improve scalability and few other reasons
b) each request from client should be self-contained
Now, I am really confused how to achieve this. Suppose we take a simple shopping cart application.
Step 1) Client sends the authentication request, server authenticates and server responds OK.
Step 2) Client sends a request to add an item to the shopping cart. Server responds OK.
Step 3) Client sends another request to add 2nd item to the shopping card. Server responds OK.
Normally, in a normally web app, a session is created in Step 1 on server and from that point onwards all the requests pertaining to that client are automatically associated with the same session and we store session state (Shopping Cart in this case) in the session object and retrieve/update it with subsequent requests from the client.
Now, in the above scenario:
1) how do we authenticate and authorize Client in Step 2 and 3 if there is no session maintained on the server ?
2) does client need to send some additional information with each request ?
3) How do we retrieve the client specific Shopping Cart in Step 3 ?
4) Does the client need to send it's Shopping Cart that was created/returned by server in Step 2 again in Step 3 ?
Obviously, this is the simplest use case and so every one developing RESTful web services must be designing their app to handle this. What is the best and most common way to handle session management, authentication, authorization in RESTful web services using RESTLet ? If we have to maintain cache on server side with the client's data then how is this different from server maintaining sessions on our behalf ?
Thanks in advance,
Deep
如果你对这篇内容有疑问，欢迎到本站社区发帖提问 参与讨论，获取更多帮助，或者扫码二维码加入 Web 技术交流群。
绑定邮箱获取回复消息
由于您还没有绑定你的真实邮箱，如果其他用户或者作者回复了您的评论，将不能在第一时间通知您！
发布评论
评论（1）
是的。您必须在每个请求中发送身份验证/授权数据。这将阻止服务器“记住”您是谁（即无状态服务器，无会话）
让我们问一个不同的问题：如果服务器重新启动会发生什么？您希望所有购物车数据丢失吗？可能不会。这意味着您必须将其存储在某个地方，以便它可以在重新启动后继续存在。意味着持久存储。可能在服务器或客户端上...
...现在，如果您的客户端重新启动怎么办？您可以选择使用 POST 请求（当用户添加第一个商品时）为该用户创建购物车“资源”，或者在客户端登录时创建它（浪费）。然后，您继续使用 PUT/DELETE 更新购物车并使用 GET 获取它。
它应该在数据库中吗？可能是这样，取决于你是否想要这样。如果它必须持久存在，那么这是保存它的好地方，这样它就可以在重新启动后继续存在。
那么如何接收客户特定的购物车呢？那么你只需发送一个资源的 GET 请求！！！就是这样！第一个 POST 将在适当的 URL 处创建一个资源，然后您就可以使用它。
Restful Web 服务也有 Restful URL，因此这是设计的关键部分。
不，如上所述。但如果您在客户端使用 cookie 或 LocalStorage 或其他一些信息，那么也许您会这样做。
是的。这很简单，但需要花一些时间来思考“资源”而不是“服务”。在 Restful 设计中，一切都是（或可以是）资源，包括交易、购物车等，
但是，授权/身份验证是 http 请求数据包的一部分，并随每个请求一起发送。我建议你仔细阅读这些内容。
差别很大！您是为了性能而缓存还是维持会话？如果系统重新启动，您的系统能否在空缓存上无缝运行？如果是，您正在缓存性能，否则您正在维护状态。
我强烈建议您阅读 Richardson & 的 RESTful Web Services。 Ruby 来启发上述概念并收集更多关于如何设计宁静服务的见解......这需要一些时间来适应。
Yes. You have to send authentication/authorization data with every request. That's what'll prevent the server from 'remembering' who you are (i.e., stateless server, no sessions)
Let's ask a different question: What happens if the server restarts? Do you want all shopping cart data to get lost? Probably not. Implying you have to store it somewhere that it can survive a restart. Implying persistent storage. Could be on server or client...
...now, what if your client restarts? You could choose to create a shopping cart 'resource' for that user using a POST request (when the user adds the first item) or have it created the moment the client logs in (wasteful). Then you continue updating the shopping cart using PUT/DELETE and fetch it using GET.
Should it be in the DB? Could be, depends if that's how you want it to be. If it has to be persistent, it's a good place to keep it so it can survive a restart.
So how to receive client specific shopping cart? Well you just send a GET request for the resource!!! That's it! The first POST will create a resource at an appropriate URL and you can then use that.
Restful web services also have restful URLs so that's a key part of the design.
No. As mentioned above. But if you are using cookies or LocalStorage or some other information on the client side, then maybe you do.
Yes. It is simple but it takes a while to think in terms of 'resources' rather than 'services'. In restful design everything is (or can be) a resource, including transactions, shopping carts etc.,
However, authorization/authentication are part of the http request packet and is sent with every request. I suggest you read up on those.
BIG difference! Are you caching for performance or maintaining a session? If the system restarts will your system work seamlessly on an empty cache? If yes you are caching for performance else you are maintaining state.
I strongly suggest you read RESTful Web Services by Richardson & Ruby to edify the above concepts and glean more insight into how are restful services designed...it takes some getting used to.