将Web UI转换为restful接口，是个好主意吗？

Question

我正在开发一个实验性的网站（可通过Web浏览器访问），它将作为RESTful接口（子系统）的前端。该网站将作为用户和RESTful接口之间的接口，因为它将对几乎所有数据库操作进行HTTP请求。身份验证可能使用OpenID完成，数据库操作的授权将通过oAuth完成。

出于好奇，这是可行的解决方案还是我应该开发两个并行访问数据库的系统（即网站具有自己的数据访问逻辑，而RESTful接口具有另一个数据访问逻辑）？如果我坚持这样做，除了每个交易将产生更多的数据库查询和HTTP请求之外，还有什么优缺点（这只是一个实验项目，让我学习像OpenID和oAuth这样的东西在现实生活中如何工作）？

- Jeffrey04

Answer 1

你的想法听起来非常可行。我认为你会在这种方法中获得相当不错的收益。首先，由于你可以在RESTful服务上放置其他前端，因此你将获得大量的代码重用。此外，你还可以相对容易地对这种架构进行单元测试。最后，你将能够让第三方开发人员访问与你使用相同的API（可能受到某些限制），这将是吸引客户和开发人员到你的平台的巨大胜利。

不过，根据你如何构建后端，你可能会遇到标准的细粒度问题。如果过于细粒度，你将为非常少量的数据建立许多连接。如果过于粗略，有时你会获得比所需更多的数据。至于安全性，你应该能够锁定后端，以便请求只能在特定条件下进行：请求包含授权令牌、API密钥等。

- Bryan Kyle

---

+1 表示“为少量数据建立大量连接” 如果存在任何延迟，这些 Web 2.1 应用程序可能会非常缓慢。 - Tarnay Kálmán

Answer 2

使用现代JavaScript库，您的方法非常简单。

ExtJS一直具有Ajax支持，但现在可以通过REST接口进行操作。

因此，您的ExtJS用户界面组件将接收URL。它们通过GET到URL自行填充，并通过POST到URL进行存储更新。

这在我目前正在处理的项目中非常有效。通过应用RESTful原则，前端和后端之间几乎存在严格的分离，这意味着替换其他内容将是微不足道的。此外，API几乎不需要记录，因为它是现有成熟标准的实现。

祝好运， Ian

- ianmayo

Answer 3

听起来不错，但我建议您只有在计划开放其余的RESTful API供其他UI使用，或者只是为了学习一些酷炫的东西时才这样做。接口支持HTML、XML和JSON。

否则，请使用一个很棒的MVC框架（比如ASP.NET MVC、Rails、CakePHP）。您最终会得到相同的基本结果，但会强制类型与数据库匹配。

- BenB

Answer 4

哇！一个来自2009年的问题！看到回答很有趣。许多人似乎不同意Web服务方法和JS前端-这已经成为了一种标准，被称为单页应用程序。

- ACV

Answer 5

我认为你概述的一般方法是相当可行的——主要优点是灵活性，主要缺点是它不能保护那些不知所措的用户免受自己的滥用。由于大多数用户可能都不知所措，这对于大众消费来说是不可行的...但是，对于真正的精英用户来说，这很好！-)

- Alex Martelli

---

Web界面应该防止这种情况发生（以及RESTful层）。 - Jeffrey04

Answer 6

所以，您想让您的Web UI调用您的Web服务，然后再调用数据库，是吗？

这正是我最近一个项目采取的路径，但我认为这是一个错误，因为您最终会创建很多额外的工作。原因如下：

当您编写Web服务时，您将创建一个库来包装数据库调用，这是典型的。没有问题。

但是，当您编写Web UI时，您最终将创建另一个库来包装对REST接口的调用...否则，进行所有原始HTTP调用将变得繁琐。

因此，您实际上创建了2个数据访问库，一个用于包装DB，另一个用于包装Web服务调用。这基本上使您的工作量翻倍，因为对于每个资源操作，您最终都要在两个库中实现。这很快就会让人感到疲倦。

更简单的替代方案是创建一个单一的库，用于包装对数据库的访问，然后从Web UI和Web服务中使用该库。

假设您的Web UI和Web服务都驻留在同一网络上，并且两者都可以直接访问后端数据库服务器（这对我来说是这种情况）。在此设置中，让两者直接访问数据库也比让UI通过Web服务更加高效。

- dso

---

我的RESTful接口只会处理一定量的工作（例如创建新资源），其他数据库请求，如身份验证（authN/Z），将通过Web用户界面直接完成（该界面使用相同的数据库访问代码）。 - Jeffrey04