深入浅出dojo/request
难度：中等Dojo版本：1.7原作者：Bryan Forbes译者：Oliver (zhuxw1984@gmail.com)原文链接：http://www.sitepen.com/blog/2012/08/21/introducing-dojorequest/
随着Dojo向着2.0大步迈进，我们已开始致力于为开发人员提供能在任何JavaScript环境下保持高效生产力的工具。这意味着我们所创建的API必须在所有环境下都保持一致。从这个角度看，有一个领域的API总是被遗漏，那就是Dojo的IO函数。我们已经为开发人员提供了在浏览器中发起请求的方法（dojo.xhr*, dojo.io.iframe, dojo.io.script），但有些人不太喜欢这些API所表现出的不一致性（例如dojo.xhrGet以及dojo.io.script.get，等等）。另外，我们还从来没有提供一套服务器端的实现；就算提供了，也肯定是另一套不同模块和API，大家就又需要记忆更多东西了。
在Dojo1.8发布之际，我们隆重推出dojo/requestAPI。这套API在所有的浏览器、所有请求方法、甚至所有JavaScript环境上都是一致的：
request.register(/^\/service1\//, function(url, options){ var promise = xhr(url, lang.delegate(options, { handleAs: "json" })), dataPromise = promise.then(function(data){ return data.items; }); return lang.delegate(dataPromise, { response: promise.response });});request.register(/^\/service2\//, function(url, options){ var promise = xhr(url, lang.delegate(options, { handleAs: "json" })), dataPromise = promise.then(function(data){ return data.data; }); return lang.delegate(dataPromise, { response: promise.response });});现在所有在用户界面中用到的服务请求都可以通过request(url, options).then(...)的形式来使用，并且它们都会接收到正确的数据。随着开发过程的进行，某个服务端团队可能决定改让/service1在data属性中以JSON格式返回数据项，而/service2则以XML的格式返回。如果不使用注册机制，这将导致大量的代码改动。有了注册机制，我们已经将我们的widget和store所需要的接口和服务所能提供的接口解耦了，这意味着服务器端团队的决定只会导致两处代码改变：在我们的两个provider中。理论上，我们甚至能将用户界面与URL进行进一步解耦，通过使用通用的URL让我们的注册机制自动将正确的服务终端映射到正确的provider上。这就避免了服务终端的改动导致的前端代码的大量修改。