REST应用程序架构

Question

我正在开发一个RESTful应用程序,其目标是允许用户跟踪他在体育活动中的结果,进度和表现.

我想为此应用创建两个或更多客户端:

1)网络客户端

2)移动客户端(iOS/Android)

我正在使用tastypie应用程序在django中编写它,我想知道我是否应该在同一个应用程序中创建Web客户端,这将提供RESTful api或者我应该将其作为纯REST服务并构建单独的Web客户端,它将通过它来联系它api？

至于现在,我没有看到将两者结合在一起的任何缺点,但我不是具有这种架构的程序的专家,所以我正在寻找一些建议背后的论证.

Answer 1

要回答这个问题并不容易,因为它很大程度上取决于您正在构建什么样的服务.

方法1:传统的Django app + API

在这里,您的Django-app和tastpie API共享通用数据模型,但以不同方式呈现它们.一个使用Djangos模板和视图,另一个使用tastypie.

优点:

• 构建传统的Web服务是相对容易且易于理解的问题
  • Django为此提供了许多工具

缺点:

• 没有保证API提供与Web服务相同的功能
• 您必须保持两种不同的方式来与您的数据进行交互.

方法2:仅限API +使用API​​的JavaScript webapp

通过tastypieAPI 只有一个服务接口.Web客户端是使用backbone.js和等的javascript工具单独构建的backbone-tastypie.

优点:

• 您保证第三方开发人员可以使用与您的Web服务相同的功能构建服务(请参阅dogfooding).
• 如果您的服务更像是一个应用程序而不是一组页面,那么可以很好地工作.

缺点:

• 客户端JavaScript工具不如Djangos(例如,模板).
• 模板的客户端呈现仅在加载大部分资源之后发生.
  • 第一页加载速度很慢
• 如果没有技巧,IE9之前的浏览器将无法运行,IE9可能需要一些技巧
• 你真的需要考虑浏览器缓存
• SEO并不像传统的Web服务那么简单.

方法3:仅API +从Django视图调用API

与方法1非常相似,但不是直接使用模型,而是在tastypie内部调用资源.

优点:

• 您仍然可以使用大多数Django工具.
• 您大多使用与潜在第三方开发人员相同的API

缺点:

• 我不知道这会产生多少开销.