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

Question

基于GUI的Web应用程序可以构建在GUI组件，像Wicket这样的有状态框架上，也可以构建为RESTful，无状态的方式，仅在客户端上具有GUI状态。

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

如果我环顾四周，很少有RESTful GUI Web应用程序。这是因为历史原因还是RESTful设计在常见情况下无效？

Answer 1

  

如果我环顾四周，很少   RESTful GUI Web应用程序。这是   因为历史原因还是一个   RESTful设计没有共同点   方案

我的回答是主观的，但在我看来，两个主要障碍阻碍了RESTful的发展：

1. 变化 - 与传统设计的方式非常不同
2. 挑战 - 设计纯RESTful服务器API和相应的丰富，强大的客户端UI并不容易

  

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

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

  

你必须留在同一页面上   只重新加载部分，

这是一种与传统请求/响应整页到完整页面设计截然不同的设计。每种设计都有自己的权衡。 REST设计在AJAX调用中运行得特别好，但客户端代码需要精心设计才能保持可维护性。

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

• 可以很好地扩展：每个用户的会话信息都不会存储在稀缺的服务器内存中
• 通过网络减少请求/响应数据：不完整发送每个页面，不发送会话ID或ViewState s
• 清理可重用的URL：提供可以支持多个UI的干净，分离的服务器API
• pure：严格遵守HTTP规范（GETs不会产生副作用等）
• 客户体验：使用异步事务更丰富，响应更快

但是，正如您所提到的，胖客户端存在缺陷：

• 更容易受到XSS攻击，RESTful URL确实需要谨慎安全
• 复杂的JavaScript在开发，维护和调试方面具有挑战性（使用OO JavaScript可以帮助调解它）
• 需要向用户表明异步请求正在后台处理
• 需要更多客户端故障处理逻辑
与服务器端相比，
• 框架和IDE工具在客户端开发方面传统上较弱（这种情况正在逐渐好转）。

Answer 2

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

Answer 3

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

我也注意到你问了一个关于desktop versus web applications的问题。您可能有兴趣知道REST也是构建桌面客户端应用程序的优秀架构。我编写了一些桌面客户端，可以从REST服务器获取所有数据。