在讨论另一个spine.js question时出现了这个问题： 因为，这与这个问题截然不同，我坚持SO的“每个帖子的一个问题”政策，将其作为一个新问题分开。
@ numbers1311407提到了
spinejs将对请求进行排队并按顺序提交，每个连续请求仅在其前任完成后才进行。
但那似乎错了！ Spine为什么要对客户端进行如此多的控制并对所有POSTS（例如）进行顺序化？如果POSTS在相关的URI上怎么办？即使Spine尝试通过为每个客户端序列化所有POST来实现某些理智，它仍然无法阻止来自不同客户端的并发和冲突的POSTS。那么，为什么要这么麻烦？
答案 0 :(得分：5)
但这似乎错了！
当您考虑脊柱的设计目标时，有意义的是，MacCaw称之为“异步UI”（您在相关问题中链接到的the blog post的标题）的实现。该范例试图从用户体验中消除传统请求/响应模式的所有痕迹。不再“加载”图形;即时响应用户交互。
这种范式期望采用不同的发展方法。持久化到服务器变得更像是一个后台线程，在正常情况下，永远不会失败。
这意味着在正常情况下，您的应用逻辑不应依赖于或关心脊椎请求的顺序或安排。
如果您的应用高度依赖服务器响应，那么spine可能是错误的库。
Spine为什么要对客户进行如此多的控制并对所有POSTS（例如）进行顺序化？
由于spine的非阻塞设计理念，您的应用程序放弃了您在其他库中可能拥有的流量控制，例如Backbone，其中您可能会执行某些操作，例如在发出请求时禁用“提交”按钮，或者< em>阻止用户使用非幂等请求向服务器发送垃圾邮件。
例如， Spine的Model#save会立即返回，就客户而言，在服务器获取请求之前就已经发生了。这意味着spinejs 需要按照它们来的顺序收集和处理请求，以确保它们得到正确处理。考虑用户在“保存”按钮上干扰新记录。第一次点击将发送一个POST，第二次点击将发送一个PUT。但按钮垃圾邮件用户不知道或不关心这一点。 Spine需要确保在发送PUT之前POST成功完成，否则客户端会出现问题。
将非阻止UI输入的顺序敏感度与第一点相结合，您的应用程序不应过多关注持久层，您可以开始查看为什么 spinejs序列化请求。
即使Spine尝试通过为每个客户端序列化所有POST来实现一定的理智，它仍然无法阻止来自不同客户端的并发和冲突的POSTS。那么，为什么要这么麻烦？
因为解决方案的目的是为单个客户端提供一致的，有点用户错误的UI体验。例如。如果客户端创建，然后更新，然后删除记录，则应确保所有这些请求成功并以正确的顺序进入服务器。处理客户端之间的冲突帖子是一个单独的问题，而不是请求队列的重点。