Django - 仅使用REST API连接项目应用程序

时间:2017-12-28 14:59:32

标签: django rest architecture project

我主要有两个问题。我没有在任何地方读到这个,但是,我想知道是否最好使它成为所有进出项目中所有应用程序的数据完全取决于REST API调用。

因此,如果您想要注册新用户。从前端收集数据,没有后端工作,只需将此数据作为REST调用发送给您“registration-app”,其中所有验证和后端工作都已完成。

我发现这种方法在大型团队工作时很有效,因为它使依赖关系更加分离,并使项目的每个部分更加分离和“清晰”。因此,我的问题是,这是一种可行的发展方式吗?这有任何安全性或性能问题吗?我在哪里可以阅读更多内容?

由于

最大

1 个答案:

答案 0 :(得分:1)

这是完全可行的,我认为像大多数选择它有利有弊。以下是其中一些:

优点:

  • 解耦 - 客户端依赖于抽象(即REST API)而非结果(即网站),因此您可以获得设计的清晰度,在浏览器之外进行测试的能力,以及您可以执行的操作,例如替换REST具有不同实现的API,例如用于开发/测试目的的模拟服务。此外,如果REST API由单独的后端服务实现,那么您可以单独更新它,并可能独立地进行扩展。
  • 响应式用户界面 - REST请求可以避免HTML页面重新加载并改善UX。您也可以进行异步REST调用。
  • 减少有效负载 - 通常,REST调用返回的数据少于页面刷新中发送的HTML数据。

缺点:

  • 更复杂的客户端 - 您需要更复杂的javascript,特别是如果您使用异步REST调用。
  • 动态页面构建 - 通常,REST调用的结果可能需要在UI中进行一些更改,您必须在javascript中动态执行此操作,这也会增加复杂性。因此,您的UI逻辑在HTML页面模板和您的javascript UI更新之间分开。这使得用户界面难以推理。
  • 超时 - 您需要处理javascript中的超时和错误
  • 会话 - 您需要一些方法来验证用户和维护会话。 REST服务本身不应维护客户端会话状态,因此您需要在客户端中存储状态,或者将状态显式添加为具有其自己的不同URI的新REST资源。
  • 强制页面重新加载 - 如果您使用此机制来避免页面重新加载,那么用户可能会在相当长的一段时间内打开页面,并且您可能需要某种机制来使其重新加载。