¿Cuál es la ventaja de usar Restangular sobre ngResource?

133

ngResourceYa parece muy simple implementar cosas con ...

¿Cuáles son las ventajas / desventajas de usar Restangular sobre ngResource ?

1.1.3 $resourcedevolverá promesas y puede ser implementado usando la última confirmación de relaciones públicas . ¿Se ofrecerá soporte futuro $resourcepara soportar verbos adicionales que Restangular? Y si eso sucede, Restangular parece que desaparecerá y se volverá irrelevante.

— Dan Kanze
fuente

41

¿Por qué cerrar? Esta es una pregunta válida que debería tener respuestas definitivas. Especialmente tan temprano en el juego cuando intentas decidir qué usar para tus llamadas de servicio. Lo que sucede en tres meses cuando este chico deja de admitir Restangular porque ngResource de Google captó todas las funciones que le faltaban. Luego, si $httpse realizan cambios importantes en la versión de angularjs --- no podrá actualizar porque las llamadas de servicio de Restangualr esperarán "algo más" y terminará destripando este marco con el que "decidió ir".

— Dan Kanze

1

Échales un

— mgonto

@DanKanze: los usuarios de SO de nivel medio están muy contentos con preguntas como esta. Es realmente frustrante ya que definitivamente no estás preguntando "cuál es mejor" ... Mi única sugerencia sería formular cuidadosamente las preguntas en el futuro para no atraer a la "Gestapo subjetiva" para que descienda sobre ti en toda su fuerza.

— rinogo

232

Soy el creador de Restangular.

He creado una sección sobre el archivo README con las diferencias con $ resource. Puede consultarlos aquí https://github.com/mgonto/restangular/blob/master/README.md#differences-with-resource

De todos modos, como resumen, además de las características adicionales y el enfoque basado en promesas, la idea es que Restangular también pueda manejar todas sus URL, para que no tenga que saber nada sobre ellas.

Suponga que tiene algo como esto para los automóviles: / users / 123 / cars / 456

En $ resource, tendría que construir esa URL manualmente y también tendría que construir el objeto $ resource para esto manualmente. Restangular te ayuda en esto "recordando" las URL.

Entonces si lo haces en algún lugar

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')

¡Espero que esto ayude!

— mgonto
fuente

45

+1 por saltar sobre esto. ¿Quién mejor para explicar que el tipo que lo construyó él mismo jaja!

— Dan Kanze

27

¿Cómo es .one('users', 123)más o menos "saber" acerca de su URL que '/users/123'? (solo jugando al defensor del diablo) Parece que '/foo/123/bar/123'es mucho más fácil que .one('foo', 123).one('bar', 123).

— Ben Lesh

55

La idea es que, en algún momento, solo conozca el nombre de la entidad y la identificación. Entonces primero haces algo mentira var user = Restangular.one('users', 123).getList(). Más adelante en el código o en algún otro controlador, lo haces user.getList('buildings'). Aquí, solo conoce el siguiente tipo que es edificios, pero consulta /users/123/buildings/, por lo que no tiene que saber la URL completa todo el tiempo

— mgonto

3

Bueno pero unilateral. La posible "irrelevancia" de Restangular se ha sugerido en este hilo con respecto a las mejoras recientes de $resource... No quiero decir que sea irrelevante de ninguna manera, solo que se ha mencionado. ¿Alguna desventaja de hecho o problema que debemos tener en cuenta?

— youri

3

¿No es mucho de lo que hay en ese archivo README desactualizado con una versión más actual de ngresource? (es decir, uso de promesas, decoración del objeto de respuesta a través de transformResponse)

— surtyaar

8

Encontré el RequestInterceptor de Restangular bastante útil para eliminar algunos campos del objeto antes de realizar la Solicitud. La mayoría de los servicios web REST con los que estoy trabajando actualmente no esperan la identificación en los datos del objeto en una solicitud PUT, por ejemplo, solo en la url. Por lo general, no esperan campos de datos adicionales que PUT no pueda actualizar (como el id o un slug que se genera al configurar el título, etc.). Descubrí que esto es sencillo con Restangular, aunque no he descubierto cómo hacerlo con $ resource de manera limpia, pero estoy seguro de que es posible de alguna manera.

Obviamente, uno también podría cambiar el servicio web para ignorar esos campos adicionales, pero eso no siempre es posible.

— awdng
fuente

3

ngResource no devuelve promesas en la última versión estable (actualmente 1.0.6). Además, parece que Restangular expone más verbos que ngResource (expone PUT, OPTIONS, PATCH, etc.).

Si no necesita verbos adicionales y está en la rama inestable de AngularJS (que incluye promesas para ngResource), no veo ninguna razón importante para usar Restangular sobre ngResource.

Use lo que le resulte más cómodo.

— rtcherry
fuente

2

1.1.3 $resourcedevolverá promesas y puede ser implementado usando el último compromiso de relaciones públicas. stackoverflow.com/questions/16429832/… ¿Se ofrecerá soporte futuro $resourcepara soportar verbos adicionales? Y si eso sucede, Restangular parece que desaparecerá y se volverá irrelevante.

— Dan Kanze

@DanKanze No estoy seguro sobre el soporte futuro para verbos adicionales. Para la mayoría de los casos de uso, los verbos adicionales no son necesarios, por lo que no esperaría que se construyan pronto, pero eso no significa que no sucederá.

— rtcherry

2

@DanKanze: dudo que sea irrelevante. Restangular proporciona un soporte mucho mejor para los recursos anidados, que es un requisito para algunos desarrolladores. Algo que Ng-resource no soporta particularmente bien. Además, ng-resource tampoco sigue las convenciones RESTful, algo de lo que he hablado en mi blog.

— Oddman 01 de

@Oddman es un buen punto sobre el acoplamiento de recursos anidados, especialmente útil para los backends de Rails.

— ardochhigh

1

Como seguimiento de las respuestas anteriores y para nuevos lectores, como yo, interesados en esos pensamientos:

"Y si eso sucede, Restangular parece que desaparecerá y se volverá irrelevante".

"Lo que sucede en tres meses cuando este tipo deja de admitir Restangular porque el ngResource de Google captó todas las funciones que le faltaban".

[ preguntado hace 2 años ]

En mi opinión, la única garantía para la supervivencia de una biblioteca de código abierto es la comunidad construida a su alrededor. un mejor ejemplo sería mariaDB y WebScaleSQL, que nacieron como una bifurcación creciente del gran sistema de gestión de bases de datos relacionales MySQL.

En este momento de escritura, Restangular having 6699 stars and 727 forksahora está avanzando hacia Restangular 2.0, que está destinado a soportar angularJs 2.0 y ES6.

discusión sobre: https://github.com/mgonto/restangular/issues/890 .
primera vista previa del repositorio: https://github.com/mgonto/restangular/tree/2.0-wip
Conferencia ng-europe presentada por mgonto: https://youtu.be/fWar75R1NGo

— Salem Ouerdani
fuente

0

Para un sitio web simple y rápido que desee ejecutar para siempre con el soporte mínimo, usaría el http HttpClient angular incorporado cuando esté trabajando en un proyecto que amo y estoy disfrutando y tratando de usar todas las tecnologías geniales. voy a usar NGX-restangular

También debe saber que ngx-restangular funciona con servicios RESTful solo como su nombre indica. Por lo tanto, para los servicios que proporcionan SOAP, no podrá usar Ngx-Restangular

https://ngx-restangular.com/

Dicho esto , usaría ngx-restangular la mayor parte del tiempo, ya que siempre trato de trabajar en un proyecto que me parece genial e intento implementar lo que creo que es mejor.

¡La mejor de las suertes!

— Nour Lababidi
fuente