看过官方文档就知道backbone的Model模块提供的fetch, save, destroy方法，和Collection模块的fetch方法，都会发送异步请求，与后端服务进行交互。然后所有这些有异步请求操作的方法，都依赖于sync这个模块，来完成请求头和请求数据的封装，以及请求回调的处理。sync这个模块，采用的是比较原始的异步请求的调用方式，比如它的成功或失败回调还是通过jQuery.ajax调用时传递的success和error这两个option来传递的，这个模块完全遵循rest接口的规范来封装请求信息和请求数据，比如HTTP请求的METHOD会根据调用的方法，选用GET POST DELETE PUT PATCH中的一种；请求数据的传递方式，不是通过form data的形式，而是通过application\json的形式。这种方式从系统接口规范管理来说，肯定是非常有好处的，因为语义化很强，接口的地址跟接口所使用的HTTP METHOD，简单明了的表达了何种资源的何种操作。但是从我个人角度而言，个人对异步请求的使用习惯，以及团队后台同事对rest接口设计的支持程度，都是我自己不想采用这种请求接口的原因，具体来说，有以下几点：

1）我个人习惯还是喜欢只用传统的GET跟POST方法，而不是非得根据对资源操作的语义然后选用DELETE PUT PATCH之类的方法。在异步请求的处理过程中，我认为有两点比较重要，第一是接口的地址，要友好要有语义，方便大家看懂；第二是请求数据和返回数据的封装形式，要便于前后端快速解析，提高工作效率；而具体用什么HTTP METHOD对工作或者对代码影响都很小，只是从整体上感知系统的设计水平不一样而已。我喜欢做一些区别很大的一些改进，而不是为了一些规范而去强加约束。

2）由于这种强rest接口的请求形式，导致请求成功与否完全取决于HTTP请求状态码是否等于200。也就是说，只有在异步请求状态码为200的时候，异步请求的success回调才会被调用，否则都会调用error回调。看过fetch等方法的源码就知道，backbone的Model模块以及Collection模块，在请求成功之后，对实例本身内部管理调用的那些东西，比如set方法，sync事件的触发，都是在success回调里面做的。这个对于那些做了自定义HTTP响应封装的后端服务来说就会存在问题，比如一个HTTP请求，如果成功，HTTP状态码是200，然后后台会返回这样的一个格式的数据：

{code: 200, data: {...}}

如果失败，HTTP状态码还是200，只不过返回的响应就是下面的一个格式的数据：

{code: 500, data: {...}}

到时候前端在回调里面，根据后端自定义的这个后端来判断请求是否成功，这个在现在的一些软件设计里面也很常见，这是后端的设计习惯，而且这种封装形式也挺好的，总比直接抛出HTTP 500要来的友好一些。但是问题就来了，因为不管HTTP请求，从业务角度而言是成功还是失败，HTTP状态码都是200，导致Backbone里面success的回调会始终被触发，而从业务角度而已，显然有一部分情况下被触发的话就是错误的逻辑。

这个问题是我个人觉得在使用rest接口时最不灵活的一个问题。

3）这种rest接口形式把系统的复杂性想的太简单了，每个系统，不是由对资源的简单的增删该查的四种操作就完成了的，做过大型一点的管理系统就知道，一个复杂的功能，可能涉及到某个实体数据的查询，就有可能划分十多个查询的场景，每种查询场景下要使用的参数或者条件都不相同，我在开发这种功能的时候，通常会采用追加一些额外的请求参数来辅助后端进行判断处理，而sync这个模块，并没有提供一个很好的方式来追加自定义的任意的请求参数。在官方文档中，我见到的唯一的一个可以传递额外参数的说明，就是Collection模块的fetch方法，如果用于一些分页查询的场景，可以通过下面的形式来传递分页参数：

Documents.fetch({data: {page: 3}})

可是要是能更灵活一些就好了阿。

以上就是我觉得在使用backbone做异步请求的时候，从个人角度发现的一些问题，我一再说明是个人角度，因为这些观点都跟我的经验能力习惯有关系，每个人只要坚持自己的方式就好。尽管如此，我还是很喜欢backbone默认的url的生成机制，因为根据model，collection生成的url，比较友好，对其它人看懂系统的请求路径有帮助，所以我会尝试一下完全在工作中使用它的这种restful的url。

有了这些问题之后，我就在想如何去解决它们，只有这样，我才能将backbone完全应用到项目中来。这两天稍微看了一下源码，如果想去改变sync模块内部对请求回调的处理，就必须去改动源码，才能去改变它回调的处理方式，后来看到了它最后对请求调用的一个处理，就发现了一个更好地方法，可以不用去改backbone的源码，只用在外部去覆盖就可以了，这个方法就是去重写Backbone.ajax这个模块，默认情况下它是对jQuery.ajax的代理，我们完全可以重写这个模块，在请求真正发送前，对请求的option做一些小小的改动，就能解决我前面说的那三个问题，把异步请求形式换成传统的方式，同时还能保证Model,Collection模块中跟异步请求相关api的正确使用。

我把这一块的代码写在了另外一个位置，感兴趣地可以去了解一下：

https://github.com/liuyunzhuge/blog/tree/master/backbone_ajax

另外也针对这一个内容，提供了一份测试地址，请参考：

不过这个地址在预览，执行里面的代码的时候，看不到我期望你看到的结果，因为这个页面是发布在gh-pages上的，github不允许这些静态页面发送post请求，所以最好的预览方法，是clone到本地区查看：）

这里要介绍的内容，如果只看官方文档中给出的todos，肯定发现不了，但是当你把todos这个应用考虑成一个真实的软件时，你就不难发现官方的todos在增删改时其实是不够的。

先来说增：