本地接口的REST？

Question

我正在构建一个小的用户管理工具，它应该与web GUI一起使用(可能是用Wicket制作的)。这个工具提供的一些服务应该是REST-ful的，现在我想知道REST是否应该是唯一的外部接口(考虑到CouchDB的REST接口)。然后，应用程序的GUI部分将进行REST调用，而不是本地方法调用。两者都将部署到同一台服务器。

REST-only接口的优点:松散耦合，统一接口。

缺点:HTTP开销大，对象需要与传输格式(如JSON)相互转换，实现起来比较困难。

这一缺点让我认为，我应该只对真正的远程接口使用REST。我错过了什么吗？

Answer 1

任何类型的远程通信都是有成本的。你应该确保你得到的东西是值得的。很多时候，支持RESTful HTTP的大量基础设施-浏览器、服务器、代理和缓存等中介、curl或wget等工具-以及后端信息变得可链接的事实，更不用说良好的标准方法、响应代码、缓存方法等都是值得的。有时它们不是-如果没有更多的应用程序细节，几乎是不可能判断的。即使这样，所有的松散耦合的好处是否大于成本仍然是一个主观的设计决定。

你可能想要考虑使用一个不会强迫你做出这样的决定的网络框架，比如，首先，对于面向人的部分，它是RESTful的。

Answer 2

您的原始接口也可以作为REST接口很好地工作。

您需要克服两个大问题。

1)许多GUI都有一个建立在接口需求之上的工作流组件。例如，一个大的表单显示为几个页面。这些主要是为人类用户做的，因为大多数计算机并不真正关心。

2)现代浏览器本身并不支持HTTP的所有动词(PUT、DELETE等)。

第一个可以结束，因为工作流可以是简单的表示，目标是正确地调用最终的REST调用。回到多页表单的示例，在表单的最后一页上，您可以将所有其他页面作为隐藏字段嵌入。所以，最后的帖子只是所有必要的数据，就像计算机最初所做的那样。

第二个可以使用简单的代理来处理。具体地说，如果你想做一个，比方说，删除，你可以将动词传递给你的代理，它将POST和verb=DELETE视为DELETE。只需确保您的后端支持这两种方式即可。或者，您可以在页面上使用Ajax进行正确的调用。

虽然通过GUI呈现的界面可能不是"REST“式的，但底层系统至少在协议级别上是”REST“的，因为它都遵循体系结构的主要约束。

您可以做的另一件事是接受URL编码的表单作为输入，但返回XML作为输出。这里的关键是您可以将XSLT样式表与XML一起发送。因此，当它在浏览器中呈现时，您将获得带有图形和按钮的完整的船HTML，以及所有其他内容。如果你通过一个通用的客户端调用它，你得到的是纯XML，没有任何"cruft“。

您可以通过使用XHTML和微格式来折中。有效负载不会比纯XML有效负载大很多，但它仍然是正常的，每天都可以在浏览器中呈现带有CSS乐趣的XHTML。

Answer 3

我的观点(这是关键)是你应该只使用REST。为什么？因为你说它是一个小的用户管理工具。这意味着它是一个小而轻量级的工具。为什么要浪费时间构建多个接口，除非很明显您需要它们？

也就是说，我不太清楚你想要做什么。什么是couchdb的GUI包装器？或者还有其他组件吗？我最初的观点可能站得住脚。