Разыменование объектов с помощью angularJS' $resource

Question

Я новичок в AngularJS, и в настоящее время я создаю веб-приложение, используя Django/Tastypie API. Это веб-приложение работает с сообщениями, а вызов API (GET) выглядит следующим образом:

{
    title: "Bootstrap: wider input field - Stack Overflow",
    link: "http://stackru.com/questions/978...",

    author: "/v1/users/1/",

    resource_uri: "/v1/posts/18/",
}

Чтобы запросить эти объекты, я создал службу angular, которая встраивает ресурсы, объявленные следующим образом:

Post: $resource(ConfigurationService.API_URL_RESOURCE + '/v1/posts/:id/')

Все работает как шарм, но я хотел бы решить две проблемы:

1. Как правильно заменить author поле по значению? Другими словами, как запросить максимально автоматически каждое ссылочное поле?
2. Как кэшировать это значение, чтобы избежать нескольких вызовов на одну конечную точку?

Опять же, я новичок в angularJS, и я мог бы что-то упустить в моем понимании $resource объект.

Спасибо, Максим.

Answer 1

Что касается первого вопроса, я не знаю ни одного тривиального, нестандартного решения. Я полагаю, что вы могли бы использовать настраиваемые преобразователи ответов для запуска дополнительных запросов $resource, прикрепляя обещания из этих запросов в качестве свойств объекта ответа (вместо URL-адресов). Последние версии фабрики $resource позволяют указывать такой преобразователь для экземпляров $resource. Вы должны делегировать глобальный преобразователь ответов по умолчанию ($httpProvider.defaults.transformResponse), чтобы получить фактический JSON, затем заменить свойства и запустить оттуда вспомогательные запросы. И помните, что при делегировании таким образом передавать по первому ДВУ, а не ОДНОМУ, параметры, которые ваш собственный преобразователь отклика получает при вызове, даже если в документации упоминается только один (я усвоил этот трудный путь).

Нет никакого способа узнать, когда было выполнено каждое последнее обещание, но я предполагаю, что у вас не будет никакого кода, который будет зависеть от этих знаний (поскольку ваш пользовательский интерфейс обычно просто привязывается к частям объекта модели, само обещание, возвращаемое исходным HTTP-запросом).

Что касается второго вопроса, я не уверен, ссылаетесь ли вы на свой основной объект (в этом случае $ scope должно быть достаточно для сохранения ссылки) или на эти вспомогательные объекты, которые вы предлагаете загрузить в качестве средства сборки агрегат на стороне клиента. Предполагая последнее, я полагаю, вы могли бы сделать что-то вроде поддержания хеша, связывающего URL-адреса с объектами в вашей области $, скажем, и иметь функции успеха в ваших дочерних $ ресурсах, обновляющих этот словарь. Затем вы могли бы заставить преобразователь ответа, который я описал выше, сначала проверить хеш, чтобы увидеть, получил ли он уже требуемый экземпляр ресурса, получая $resource от серверной части, только когда такая локальная копия отсутствует.

Это все куча работы (и циклические обходы) по сбору ресурсов на стороне клиента, когда может быть гораздо проще просто собрать агрегат на уровне приложений и подготовить его предварительно подготовленным. REST не устанавливает ожиданий для нормализации данных.