几个月前我正在研究一些Odata WCF项目，我在解析令牌auth（apiKey）的自定义标头时遇到了一些问题。
当时，我是一个非常棒的人（我还是！），我发布了这个问题：JayData oData request with custom headers
今天我正在与Jaydata Odata服务器和客户端库合作开发一个新项目，并且：
application.context.prepareRequest = function (r) {
r[0].headers['apikey'] = '123456';
};
工作正常，直到我不得不做MERGE次请求。我发现MERGE请求以某种方式覆盖了我的标题，所以我进一步调查了。
首先，在_saveRest方法的oDataProvider.js（〜第617行）中，标题不会被继承：
request = {
requestUri: this.providerConfiguration.oDataServiceHost + '/',
headers: {
MaxDataServiceVersion: this.providerConfiguration.maxDataServiceVersion
}
};
但稍后我们会得到：
this.context.prepareRequest.call(this, requestData);
“应该”调用我自己的prepareRequest，但不是......相反它仍然指向：
//Line 11302 jaydata.js
prepareRequest: function () { },
当然没有......没有！很有趣，当你执行一个简单的GET时，假设同一个context实例上的相同代码可以正常工作并指向我的prepareRequest覆盖。
我可以充满信心断言GET / MERGE之间的上下文不是同一个实例。但是，我无法看到context实例被重新分配的任何地方。
有没有人知道？
PS：这不是CORS问题。我的OPTIONS传递正常，并在oDataProvider工作中手动输入标题。
我跟踪了不同上下文实例的主角，发现了一些有趣的东西。调用EntitySet.save()最终会调用EntityContext构造函数。见踪迹：
$data.Class.define.constructor (jaydata.js:10015)
EntityContext (VM110762:7)
Service (VM110840:8)
storeToken.factory (jaydata.js:14166)
$data.Class.define._getContextPromise (jaydata.js:13725)
$data.Class.define._getStoreContext (jaydata.js:13700)
$data.Class.define._getStoreEntitySet (jaydata.js:13756)
$data.Class.define.EntityInstanceSave (jaydata.js:13837)
$data.Entity.$data.Class.define.save (jaydata.js:9774)
(anonymous function) (app.js:162) // My save()
这就解释了为什么我会得到两个不同的实例......
在类定义中直接替换prepareRequest函数有效，但它很难看！
现在我可以应付这个：
$data.EntityContext.prototype.prepareRequest = function (r) {
r[0].headers['apikey'] = '12345';
};
只要您只需要与单个端点通信，这就可以正常工作。
就像我喜欢JayData一样，很明显他们创造了一个怪物而且它已经失控了（糟糕的论坛，没有社区，有一半记录，......）。
我之所以选择JD，是因为我很懒，想继续使用旧的WCF DataService。切换到Web API似乎是错误的，或者对我来说太多了。
同样作为.net开发人员，我喜欢我的实体的强类型以及使用JD工具生成的具体模型的能力。然而，最后，我加入了混乱。每次我的服务器端模型改变时，我都必须获取新的元数据并构建一个新的entityModel。
我最终切换到Web Api并将我的数据服务层迁移到Breeze。并且认真！轻而易举地使用它！
文档绝对精彩，在S.O上你可以依靠Ward或Jay Tarband以极高的专业水平回复。
最后我意识到这应该是一个维基而不是一个问题......