是的，它会起作用。但是，您的分布式系统设计基于数据模型非常简单并将保持这种方式的假设。如果您正在构建的应用程序成功，您可以确定将添加新需求并请求新功能。
按照您的建议公开数据层，将您的客户端应用程序与数据模型紧密耦合，并且您对 http 的使用使得进行多请求事务非常困难。我知道你说过你不需要做多请求事务。不是今天，可能是明年？
此应用程序的预期寿命是多少？如果您说超过几年，那么我会重新考虑将数据层暴露给远程客户端的想法。REST 的主要目标之一是将客户端和服务器应用程序解耦，以允许应用程序在很长一段时间内发展。如果您有多个客户端应用程序访问一个分布式服务（如果设计不正确），它可能会很快遇到令人讨厌的维护和版本控制问题。
编辑以回答有关客户需要了解模型的评论中的问题：
关于客户端如何与从服务器接收到的表示进行交互，您可以采取两个不同的方向。
- 您可以允许客户端明确了解表示中包含的数据内容。即客户端知道某些 XML 元素中存在用户名和密码。但是，如果您这样做，您应该返回一个特定的媒体类型，例如 application/vnd.mycompany.user+xml。您不应使用 application/xml，因为它不会告诉客户端有关 XML 文档中的内容的任何信息。如果客户端知道“当您转到 url X 时”您会得到“一个包含元素 User 内的 UserName 和 Password 元素的 Xml 文档”，那么您就违反了 REST 的自描述约束。影响是您已将端点耦合到媒体类型，并且实际上将客户端耦合到该端点。“超媒体约束”的意图
- 另一种方法是使用更通用的媒体类型，它只是旨在向客户端提供要显示给用户的内容，并向用户提供选项以允许客户端采取行动。html 媒体类型允许您通过提供可用于在两个 div 标签中返回用户名和密码的标记语言来做到这一点。使用 html FORM 标签和 A 标签，客户端可以对该资源执行额外的操作。弄清楚如何以真正的 RESTful 方式使“用户”对象可能具有的所有可能操作可访问，这很棘手，需要相当多的经验，但最终结果是客户端和服务器的解耦非常好。以网络浏览器为例，您需要多久更新一次浏览器，因为网站更改了其内容。
选项二的问题在于，仅使用 HTML 最终用户体验往往受到很大限制，这就是 Javascript 的用武之地。“可选”REST 限制之一是代码下载的使用。Javascript 是从服务器加载的代码，用于在客户端启用其他行为。不幸的是，在我看来，它还为人们提供了创建返回 application/xml 的 RESTful Web 界面然后使用 javascript 来解释该通用格式的能力。此解决方案适用于使用 RESTful API 的网站的原始开发人员，因为如果 xml 文件的内容发生更改，则可以更改 javascript 并将其重新下载到浏览器，一切都很好。然而，对于访问此 API 且无法控制应用程序/xml 内容模型的任何其他第三方开发人员，他们的代码将变得非常脆弱，并且如果 API 内容更改，则可能会中断。询问任何为 Twitter 编写过任何类型客户端的人，他们的应用程序因 Twitter 更改内容而损坏了多少次。
通过使用第一个选项并为内容提供特定的媒体类型，服务器开发人员可以引入名为 application/vnd.mycompany.userV2+xml 的新媒体类型，并且使用内容协商，现有客户端仍然可以接收原始媒体类型和新的可以构建客户端以使用新的媒体类型。url 保持不变，书签没有损坏，因为端点和媒体类型没有耦合。
如果您看到提供 URL 列表和从这些 url 返回的内容的 API 文档，那么很可能这些开发人员没有获得 REST，也不会获得 RESTful 接口提供的好处。具有讽刺意味的是，受害最大的不是那些开发人员，而是试图与 API 交互的第 3 方受害！