我主要有两个问题。我还没有在任何地方读过这篇文章，但是我想知道制作它是否是一个好主意，以便所有项目中所有应用程序中的所有数据都完全取决于REST API呼叫。
这样，例如，如果您想注册新用户。从前端收集数据，没有后端工作，只需将此数据作为休息呼叫发送给您的"注册"应用程序，其中所有验证和后端工作都已完成。
在大型团队中工作时，我发现这种方法有效，因为它使依赖关系更加脱钩，并使项目的每个部分都更加分开和"清晰"。因此，我的问题是，这是一种可行的发展方式吗？有任何安全性或性能问题吗？我在哪里可以阅读更多？
谢谢
最大
它是完全可行的，我认为就像大多数选择一样，它具有优点和缺点。这是其中一些：
专利：
- deClpling-客户端取决于抽象（即剩余的API），而不是具体（即网站），因此您可以清楚设计，可以在浏览器外面进行测试，并且您可以做诸如替代其余的事情之类的事情具有不同实现的API，例如具有用于开发/测试目的的模拟服务。此外，如果由单独的后端服务实现了REST API，则可以独立更新并可能独立扩展。
- 响应式用户界面 - 其余的请求可以避免HTML页面重新加载并改进UX。您也可以进行异步的休息电话。
- 减少有效载荷 - 通常，其余的呼叫将返回的数据少于页面刷新中发送的HTML。
cons：
- 更复杂的客户端 - 您需要更复杂的JavaScript，尤其是您使用异步呼叫的情况。
- 动态页面构建 - 通常是REST调用的结果可能需要在UI中进行一些更改，您被迫在JavaScript中动态执行此操作，这也增加了并发症。因此，您的UI逻辑分为HTML页面模板和JavaScript UI更新。这使UI很难推理。
- 超时 - 您需要处理JavaScript中的超时和错误
- 会议 - 您需要一些对用户进行认证和维护会议的方法。REST服务不应保留客户主持人状态，因此您要么需要将状态存储在客户端中，要么将状态显式添加为具有自己独特的URI的新的REST资源。
- 强制页面重新加载 - 如果您使用此机制避免页面重新加载，则用户可能会在很长的一段时间内打开页面，并且您可能需要某种机制来使其重新加载。