Запрос JayData oData с пользовательскими заголовками - ROUND 2

Question

Несколько месяцев назад я работал над одним проектом WCF для Odata, и у меня возникли проблемы с анализом пользовательских заголовков для аутентификации токена (apiKey).

В то время, будучи довольно нубом (все еще я!), Я разместил этот SO вопрос: Запрос oData JayData с пользовательскими заголовками

Сегодня я работаю над новым проектом с сервером Jaydata Odata и клиентской библиотекой, и это:

 application.context.prepareRequest = function (r) {
     r[0].headers['apikey'] = '123456';
 };

работал хорошо, пока я не должен был сделать MERGE запрос. Я обнаружил, что каким-то образом MERGE-запрос переопределяет мои заголовки, поэтому я продолжил расследование.

Сначала кажется, что в oDataProvider.js (~ строка 617) в _saveRest Метод заголовки не наследуются:

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 вопрос. Мои ОПЦИИ проходят нормально, и подача заголовков вручную в 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. И серьезно! работать с ним проще простого!

Документация абсолютно блестящая, и здесь, на SO, вы всегда можете рассчитывать на Уорда или Джея Тарбанда, которые ответят с очень высоким профессионализмом.

В конце концов, я понимаю, что это должно быть скорее вики, чем вопрос.....