ngResource уже кажется очень простым для реализации вещей с...
Каковы преимущества/недостатки использования Restangular над ngResource?
1.1.3 $resource вернет promises и может быть имплантирован с помощью последней фиксации PR. Будет ли поддержка в будущем поддерживаться $resource для поддержки дополнительных глаголов, которые делает Restangular? И если это произойдет, то Restangular кажется, что он исчезнет и станет нерелигиозным.
Я создатель Restangular.
Я создал раздел в README с отличиями от $resource. Вы можете проверить их здесь https://github.com/mgonto/restangular/blob/master/README.md#differences-with-resource
В любом случае, как итог, помимо дополнительных функций и подхода, основанного на обещаниях, идея заключается в том, что Restangular может также обрабатывать все ваши URL-адреса, чтобы вам не было ничего о них знать.
Предположим, что у вас есть что-то вроде этого для автомобилей:/users/123/cars/456
В $resource вам придется создать этот URL вручную, и вам придется также создать объект $resource для этого вручную. Restangular помогает вам в этом, "запоминая" URL-адреса.
Итак, если вы делаете в некотором месте
Restangular.one("users", 123).get().then(function(user) {
$scope.user = user;
});
// Some other code
//Automatically does the request to /users/123/cars as it remembers in which object you're asking it.
$scope.user.getList('cars')
Надеюсь, это поможет!
Я нашел Restangular RequestInterceptor весьма удобным для удаления некоторых полей из объекта перед тем, как сделать запрос. Большинство веб-сервисов REST, с которыми я сейчас работаю, не ожидают идентификатора в данных объекта в запросе PUT, например, только в URL-адресе. Как правило, они не ожидают дополнительных полей данных, которые не могут быть обновлены PUT (например, id или slug, который генерируется установкой заголовка и т.д.). Я обнаружил, что это просто с помощью Restangular, пока я не понял, как это сделать с $resource в чистом виде, но я уверен, что это возможно как-то.
Очевидно, можно также изменить веб-сервис, чтобы просто игнорировать эти дополнительные поля, но это не всегда возможно.
ngResource не возвращает promises в последней стабильной версии (в настоящее время 1.0.6). Кроме того, похоже, что Restangular предоставляет больше глаголов, чем ngResource (он предоставляет PUT, OPTIONS, PATCH и т.д.).
Если вам не нужны дополнительные глаголы и находятся на нестабильной ветки AngularJS (которая включает promises для ngResource), я не вижу основной причины использовать Restangular над ngResource.
Используйте все, что вам удобно.
Следуя приведенным выше ответам и новым читателям, таким как я, интересуюсь этими мыслями:
"И если это произойдет, то, как кажется, это будет исчезнуть и стать нерелигиозным."
"Что происходит через три месяца, когда этот парень отказывается от поддержки Строго говоря, потому что Google ngResource догнал все функции он отсутствовал".
По моему мнению, единственной гарантией существования библиотеки с открытым исходным кодом является создание сообщества вокруг нее. лучшим примером может служить mariaDB и WebScaleSQL, которые оба из них рождаются как растущая вилка для большой системы управления реляционными базами данных MySQL.
В это время записи Restangular having 6699 stars and 727 forks теперь переходит к Restangular 2.0, который предназначен для поддержки угловых JS 2.0 и ES6.