我正在构建一个小的用户管理工具，它应该与Web GUI一起使用（可能是用Wicket制作的）。这个工具提供的一些服务应该是REST-ful，现在我想知道REST是否应该是唯一的外部接口（考虑到具有REST接口的CouchDB）。然后，应用程序的GUI部分将进行REST调用而不是本地方法调用。两者都将部署到同一台服务器上。
仅REST接口的优点：松散耦合，统一接口。
缺点：HTTP-Overhead，对象需要转换为传输格式（如JSON），更难实现。
这个缺点让我想一想，我应该只将REST用于真正的远程接口。我错过了什么吗？
答案 0 :(得分：2)
任何类型的远程通信都需要付费。你应该确保你获得了值得的东西。通常，可用于支持RESTful HTTP的大量基础架构 - 浏览器，服务器，代理和缓存等中介，curl或wget等工具 - 以及后端内部信息变得可链接的事实，更不用说虽然标准方法，响应代码，缓存方法等是值得的。有时它们不是 - 如果没有更多应用程序的详细信息，几乎无法分辨。即便如此，所有松散耦合效益是否超过成本仍然是一个主观的设计决策。
你可能想要考虑使用一个Web框架，它不会强迫你做出决定，即首先是面向人类的部分的RESTful。
答案 1 :(得分：2)
您的原始界面也可以作为REST界面使用。
您需要克服两大问题。
1）许多GUI都有一个基于接口要求构建的工作流组件。例如，一个大表单显示为多个页面。这些主要是为人类用户完成的，因为大多数计算机并不真正关心。
2）现代浏览器本身不支持HTTP的所有动词（PUT，DELETE等）。
第一个可以结束，因为工作流可以是简单的表示，目标是他们正确调用最终的REST调用。回到多页面表单示例，在表单的最后一页上，您可以将所有其他页面嵌入，例如隐藏字段。因此，最终的POST只是所有必要的数据，就像计算机最初会做的那样。
可以使用简单代理处理第二个。具体来说，如果你想做一个，比方说，DELETE，你可以将动词传递给你的代理，它将POST和动词= DELETE视为DELETE。只需确保您的后端支持类似。或者您可以在页面上使用Ajax来拨打正确的电话。
虽然通过GUI呈现的界面可能不是一个迂腐的“REST”，但底层系统至少在协议级别，因为它都遵循架构的主要约束。
您可以做的另一件事是接受URL编码表单作为输入，但返回XML作为输出。这里的关键是您可以将XML与XSLT样式表一起发送。因此，当它在浏览器中呈现时，您将获得带有图形和按钮的完整船只HTML，以及其他所有内容。如果你通过一个通用的客户端来调用它，那么你就得到了纯粹的XML而没有任何“残缺”。
您可以通过使用XHTML和微格式来满足。有效载荷不会比纯XML有效载荷大得多，但它仍然是正常的，每天都有带有CSS的XHTML，可以在浏览器中进行渲染。
答案 2 :(得分：0)
我的意见（这是关键）是你应该只坚持使用REST。为什么？因为你说它是一个小用户管理工具。这意味着它是一个小巧轻便的工具。为什么浪费时间构建多个接口，除非你明白你需要它们？
说，我不太清楚你要做什么。一个基本上是couchdb的GUI包装器？还是有其他组件？我原来的意见可能会坚持..