REST 是 GUI Web 应用程序的不错选择吗?

发布于 2024-08-20 05:59:10 字数 386 浏览 5 评论 0原文

基于 GUI 的 Web 应用程序可以构建在 GUI 组件、有状态框架(如 Wicket)上,也可以以 RESTful、无状态方式构建,仅在客户端上具有 GUI 状态。

从技术角度来看,REST 看起来是正确的方式,因为它充分利用了 http 的强大功能并带来了高度可扩展的应用程序。但这是有代价的。在许多情况下,复杂的 GUI 需要客户端上有 JavaScript 应用程序。如果应在客户端上维护状态,您必须保持在同一页面上并仅重新加载部分。或者你必须使用隐藏 iframe 的技巧。有时,服务器上会有购物车等伪资源,以实现 RESTful 设计。你必须维护多步对话的中间状态等等......

如果我环顾四周,很少有 RESTful GUI Web 应用程序。这是因为历史原因还是 RESTful 设计在常见场景中效率低下?

GUI based web applications could be build upon a GUI component, stateful framework like Wicket or they could build in a RESTful, stateless way with GUI status only on the client.

From a technical point of view REST looks like the right way since it leverages the full power of http and leads to highly scalable applications. But that comes at a price. Complex GUIs will require a JavaScript application on the client in many cases. You have to stay on the same page and reload only parts, if state should be maintained on the client. Or you have to use tricks with hidden iframes. Sometimes there are pseudo resource like shopping carts on the server, to enable a RESTful design. You have to maintain intermediate state of multi step dialogues and so on ...

If I look around there are very few RESTful GUI webapplications. Is this because of historical reasons or is a RESTful design unproductive in common scenarios?

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

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

发布评论

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

评论(3

眼眸 2024-08-27 05:59:10

环顾四周,发现很少
RESTful GUI Web 应用程序。这是
由于历史原因或者是
RESTful 设计的共同点是效率低下
场景?

我的答案是主观的,但在我看来,有两个主要障碍阻碍了 RESTful 开发:

  1. 变化 - 它与传统网站的设计方式非常不同
  2. 挑战 - 设计一个纯粹的 RESTful 服务器 API 和相应的丰富、健壮的客户端 UI 并不容易

复杂的 GUI 需要 JavaScript
在许多客户端上应用
案例。

在我看来,复杂、丰富的客户端体验将需要一些深入的 JavaScript,无论服务器端实现如何。

你们必须保持一致并且
仅重新加载部分,

这是与传统请求/响应整页到整页设计非常不同的设计。每种设计都有自己的权衡。 REST 设计特别适用于 AJAX 调用,但客户端代码需要仔细设计才能保持可维护性和健壮性。

具有胖客户端的 RESTful 服务器:

  • 可扩展性良好:每个用户的会话信息不会存储在稀缺的服务器内存中
  • 网络上的请求/响应数据较少:不完整发送每个页面,不发送会话 ID 或 ViewState 干净的可重用URL
  • :提供干净、解耦的服务器 API,可以支持多个 UI
  • 纯粹:严格遵守 HTTP 规范(GET 不会造成副作用等)
  • 客户端体验:异步事务更丰富、响应更快

然而,正如您提到的,胖客户端有缺点:

  • 更容易受到 XSS 攻击,RESTful URL 确实需要仔细的安全性,
  • 复杂的 JavaScript 开发、维护和调试可能具有挑战性(使用 OO JavaScript 可以帮助解决这个问题),
  • 需要指出异步请求在后台处理的用户
  • 需要更多的客户端故障处理逻辑
  • 与服务器端相比,框架和 IDE 工具传统上对于客户端开发来说较弱(这正在慢慢变得更好)

If I look around there are very few
RESTful GUI webapplications. Is this
because of historical reasons or is a
RESTful design unproductive in common
scenarios?

My answer is subjective, but in my opinion, two major hurdles hinder RESTful development:

  1. Change - it very different from the way sites are traditionally designed
  2. Challenge - designing a pure RESTful server API and a corresponding rich, robust client UI isn't easy

Complex GUIs will require a JavaScript
application on the client in many
cases.

In my opinion, a complex, a rich client-side experience is going to require some in-depth JavaScript, regardless of the server-side implementation.

You have to stay on the same page and
reload only parts,

This is a very different design from the traditional request/response full-page-to-full-page design. Each design has its own trade offs. REST designs work particularly well with AJAX calls, but the client-side code requires careful design to be maintainable and robust.

A RESTful server with a thick-client:

  • scales well: session information for every user isn't stored in scarce server memory
  • less request/response data over the wire: not sending every page in full, not sending session IDs or ViewStates
  • clean reusable URLs: provide a clean, decoupled server API that can support multiple UIs
  • pure: strict adherence to the HTTP specification (GETs cause no side effects, etc.)
  • client experience: richer, more responsive with asynchronous transactions

However, as you mentioned thick-clients have drawbacks:

  • more vulnerable to XSS attacks, RESTful URLs really need careful security
  • complex JavaScript can be challenging to develop, maintain, and debug (using OO JavaScript can help mediate this)
  • there is a need to indicate to the user that asynchronous requests are processing in the background
  • more client-side failure-handling logic is required
  • frameworks and IDE tools have been traditionally weaker for client-side development, compared to server-side (this is slowly getting better)
琴流音 2024-08-27 05:59:10

恕我直言,RESTful GUI 设计非常高效。您可以利用许多功能,而无需额外的工作来支持极端情况,例如用户重新提交信息、浏览器历史记录(后退和前进)、多个选项卡和窗口。如果我没记错的话,这个网站使用 RESTful UI。

RESTful GUI designs are very productive, IMHO. You can leverage a lot of functionality without extra work to support the corner cases, such as the user resubmitting information, browser history (back and forward) multiple tabs and windows. If I'm not mistaken this site uses a RESTful UI.

深爱不及久伴 2024-08-27 05:59:10

REST 是通过观察成功的 Web 应用程序(GUI 和 M2M)的特征来定义的。因此,根据定义,它应该适合这些情况。

我还注意到您提出了有关桌面应用程序与网络应用程序的问题。您可能有兴趣了解 REST 也是构建桌面客户端应用程序的出色架构。我编写了一些桌面客户端,它们从 REST 服务器获取所有数据。

REST was defined by observing characteristic of successful web applications, both GUI and M2M. Therefore by definition it should be appropriate for these cases.

I also noticed you asked a question regarding desktop versus web applications. You may be interested to know that REST is an excellent architecture for building desktop client applications too. I have written a few desktop clients that get all of their data from a REST server.

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