在基于 RESTful 的应用程序中管理状态

发布于 2024-12-22 16:55:50 字数 407 浏览 1 评论 0原文

我们正在评估用于基于 Web 的应用程序的技术,并提出一些建议以采用基于 RESTful 的服务方法。 技术堆栈

1) Spring 2)Apache CXF(JAX-RS)

我的问题是

1)如何在请求之间管理状态。例如,用户已经过身份验证,现在他正在发出一系列请求,比如说浏览分页报告。我想这个 URL 会像

domain.com/reports/customreport/page/1 domain.com/reports/customreport/page/2 等等...

a) 用户信息在哪里&存储请求参数,以便可以在请求之间共享。 b) 假设结果正在流式传输,Rowset 存储在哪里?

是否有一个类似于 Petclinic 的完整示例应用程序可以为此类应用程序提供最佳实践。

We are evaluating the technology to be used for a web based application and some suggestions are to go with RESTful based services approach.
Tech Stack

1) Spring
2) Apache CXF ( JAX-RS)

My questions are

1) How state is managed between requests. For example, a user has been authenticated and now he is making a series of requests lets say going through a paginated report. I would imagine the URL for this will be like

domain.com/reports/customreport/page/1
domain.com/reports/customreport/page/2
etc...

a) Where is the user information & request parameters are stored so that it can be shared between requests.
b) Lets say the result is being streamed, where is Rowset is stored?

Is there a complete sample application something similar to Petclinic that can provide the best practices for such an application.

如果你对这篇内容有疑问,欢迎到本站社区发帖提问 参与讨论,获取更多帮助,或者扫码二维码加入 Web 技术交流群。

扫码二维码加入Web技术交流群

发布评论

需要 登录 才能够评论, 你可以免费 注册 一个本站的账号。

评论(2

白芷 2024-12-29 16:55:50

如果您严格/正确地执行 RESTful,那么用户身份验证将在每个请求中完成,并且不存在会话的概念。每个请求都包含足够的上下文信息(在 URL 和/或请求参数中),以允许其独立于会话工作。

1) 如何在请求之间管理状态。

它必须由客户端管理。

a) 用户信息在哪里?存储请求参数,以便可以在请求之间共享。

用户身份验证信息由客户端存储并随每个请求提供给服务器。服务器将重新计算每个请求中有关用户的任何派生信息。通常存储在服务器端“会话”中的任何请求参数都必须随每个请求重新传递。

b) 假设结果正在流式传输,Rowset 存储在哪里?

第一瞬间,无处可去。每次都会重新发出查询,并带有一个指示跳到哪里的参数。如果性能是一个问题,您可以

  • 预读结果集的几页并将它们存储在服务器端缓存中,或者
  • 调整查询的数据库查询缓存。

If you are doing RESTful strictly / properly, then user authentication is done in each request and there is no concept of a session. Each request contains enough context information (in the URL and/or request parameters) to allow it to work independent of a session.

1) How state is managed between requests.

It must be managed by the client.

a) Where is the user information & request parameters are stored so that it can be shared between requests.

User authentication information is stored by the client and provided to the server with each request. The server will recalculate any derived information about the user on each request. Any request parameters that would normally be stored in a server-side "session" must be passed afresh with each request.

b) Lets say the result is being streamed, where is Rowset is stored?

In the first instant, nowhere. The query is reissued each time with a parameter saying where to skip to. If performance was an issue, you could

  • read-ahead a few pages of the result set and store them in a server-side cache, or
  • tune the database query caching for the query.
嗫嚅 2024-12-29 16:55:50

1)用户信息不存储在任何地方,用户必须在每个请求中发送他的凭据(或您正在使用的任何身份验证方法)。

2)流式传输在 RESTful API 中没有多大意义,如果您想要进行流式传输,我强烈建议您寻找类似 WebSockets 的东西(在 Java 中您可以轻松地做到这一点 与 Jetty)

如果您说的是流式处理,但您指的是分页结果,与 1 相同,则没有状态保持,客户端必须发送包含所有信息的新请求,服务器必须查询数据库(或转到缓存,或执行任何需要的操作)并将结果返回给客户。

您还应该阅读有关 REST 的更多信息,因为您的问题相当模糊,一个好的开始是 Restful Web Services 书籍,或者,如果您喜欢冒险,您可以尝试Roy Fielding 论文定义了我们今天所说的 REST。

1) The user information is not stored anywhere, the user has to send his credentials (or whatever authentication method you're using) on every single request.

2) Streaming doesn't make much sense in a RESTful API, if you would like to do streaming I'd greatly advice you to look for something like WebSockets (in Java you can easily do this with Jetty)

If you said streaming but you meant paginated results, same as 1, there is no state kept, the client has to send a new request with all the information and the server has to query the database (or go to a cache, or do anything needed) and return the result to the customer.

You should also read more about REST, as your question is quite vague, one good start is the Restful Web Services book or, if you feel adventurous, you can try Roy Fielding dissertation that defined what we call REST today.

~没有更多了~
我们使用 Cookies 和其他技术来定制您的体验包括您的登录状态等。通过阅读我们的 隐私政策 了解更多相关信息。 单击 接受 或继续使用网站,即表示您同意使用 Cookies 和您的相关数据。
原文