我无法理解使用Django Rest Framework中的RESTful API制作单页骨干应用程序时,以下方法的优缺点。
有什么需要注意的事项,即每种策略中的注意事项。有没有其他方法可以将它们捆绑起来,我错过了?
这是一个非常广泛的问题,实际上它与Django或Backbone无关。您真正要问的是“胖客户端”架构与“瘦客户端”架构。换句话说,让您的用户界面在客户端上呈现,而不是在服务器上呈现它。
首先,请允许我回顾一些事情,以确保我们在同一页面上。 “瘦客户端”方法是传统/旧学校模式,Django模型本身就是基于。服务器呈现HTML,将其发送到客户端,每当客户端想要做某事时,它都会将数据发送回服务器并要求提供新的HTML。
相比之下,更现代的“胖客户端”方法允许客户端呈现所有UI。每当客户端需要做某事时,它就会向一个(可能是REST-ful)API发出AJAX请求,该API由Django REST Framework等库提供支持。该API只返回相关数据,并将其留给客户端以适当地呈现它。
这两种方法都有优点和缺点,但胖客户端方法正变得越来越流行,因为:
这就是为什么很多公司(包括我工作的公司)都已经放弃了Django,而选择了Django REST Framework提供的API端点。
因此,如果你想使用厚客户端架构,Django应该永远不会提供除第一个HTML页面之外的任何东西(如果你愿意,甚至可以由ngnix提供,因为它只是静态HTML)。之后你会使用Backbone.Router
和Backbone.Views
来渲染你的网站。每当您需要来自服务器的新信息时,您需要fetch
Backbone.Model
或Backbone.Collection
(其url
属性指向您的Django REST Framework端点)。
我可以证明这整个方法很有效;我工作的网站非常复杂,有许多端点,Backbone + Django REST Framework可以很好地处理它。唯一(稍微)棘手的部分是缓存:在瘦客户端方法中,浏览器会自动为您缓存页面,但由于胖客户端中没有“页面”(只有带数据的AJAX响应),因此没有自动缓存。这意味着如果你想缓存数据,你需要自己做,例如使用专门用于此目的的Backbone.Collection
。
希望有所帮助。
附:回到当天,Django REST Framework没有按照我们想要的方式处理Django身份验证的东西(即登录/退出),所以我们从Django开始服务另一个页面,即我们的登录页面。但是我很确定当前的Django REST框架现在可以更好地处理身份验证,所以这对您来说可能不是问题。