Tengo algunos servicios web a los que quiero llamar. $resource
o $http
, ¿cuál debo usar?
$resource
: https://docs.angularjs.org/api/ngResource/service/$resource
$http
: https://docs.angularjs.org/api/ng/service/$http
Después de leer las dos páginas API anteriores, estoy perdido.
¿Podría explicarme en inglés sencillo cuál es la diferencia y en qué situación debo usarlos? ¿Cómo estructuro estas llamadas y leo los resultados en objetos js correctamente?
Respuestas:
$http
es de uso general AJAX. En la mayoría de los casos, esto es lo que usará. Con$http
vas a estar haciendoGET
,POST
,DELETE
tipo manual de llamadas y procesamiento de los objetos regresan por su cuenta.$resource
envolturas$http
para su uso en escenarios de API web RESTful.Hablando muy en general: Un servicio web REST será un servicio con un punto final para un tipo de datos que hace cosas diferentes con ese tipo de datos basado en HTTP métodos como
GET
,POST
,PUT
,DELETE
, etc Por lo tanto con una$resource
, puede llamar a unaGET
para conseguir el recurso como un objeto JavaScript, luego modifíquelo y envíelo de vuelta con unPOST
, o incluso elimínelo conDELETE
.... Si eso tiene sentido.
fuente
$resource
servicio sólo sería idiomática / bueno si sus soportes RESTO de punto finalGET
,POST
, yDELETE
? Los documentos ( docs.angularjs.org/api/ngResource.$resource ) muestran que obtienes estos 3 métodos REST$resource
.PUT
o cualquier otra cosa que deseeGET
,POST
yDELETE
son solo valores predeterminados. Si tiene un punto final que trata con el mismo recurso (eso es importante) para más de un método HTTP, entonces$resource
es una buena opción..$promise
funciona bienresolve
para el enrutamiento y el enlace.Siento que otras respuestas, aunque correctas, no explican la raíz de la pregunta:
REST
es un subconjunto deHTTP
. Esto significa que todo lo que se puede hacer a través deREST
se puede hacer a través deHTTP
pero no todo lo que se puede hacer a través deHTTP
se puede hacer a través deREST
. Es por eso que$resource
utiliza$http
internamente.Entonces, ¿cuándo usarnos?
Si todo lo que necesita es
REST
, es decir, si está intentando acceder a un servicioRESTful
web, le$resource
será muy fácil interactuar con ese servicio web.Si, en cambio, está intentando acceder a CUALQUIER COSA que no sea un servicio
RESTful
web, tendrá que hacerlo$http
. Tenga en cuenta que también puede acceder a un servicioRESTful
web a través de$http
, será mucho más engorroso que con$resource
. Esta es la forma en que la mayoría de la gente lo ha estado haciendo fuera de AngularJS, utilizandojQuery.ajax
(equivalente a Angular's$http
).fuente
$http
realiza una llamada AJAX de propósito general, en la que en general significa que puede incluir una API RESTful más una API no RESTful .y
$resource
está especializado para esa parte RESTful .La API de reposo prevaleció en los últimos años porque la URL está mejor organizada en lugar de una URL aleatoria compuesta por programadores.
Si uso una API RESTful para construir la url, sería algo así
/api/cars/:carId
.$resource
forma de obtener datosEsto le dará un objeto de recursos , que se acompaña con
get
,save
,query
,remove
,delete
métodos automáticamente.$http
forma de obtener datosVea cómo necesitamos definir cada operación común en la API RESTFul . También una diferencia es que
$http
devuelvepromise
mientras$resource
devuelve un objeto. También hay complementos de terceros para ayudar a Angular a lidiar con RESTFul API como restangularSi la API es algo así
/api/getcarsinfo
. Todo lo que nos queda es usar$http
.fuente
/api/getcarsinfo
, supongo que todavía podemos usar$resource
Creo que la respuesta depende más de quién eres en el momento en que escribes el código. Úselo
$http
si es nuevo en Angular, hasta que sepa por qué lo necesita$resource
. Hasta que tenga una experiencia concreta de cómo lo$http
está frenando, y comprenda las implicaciones de usar$resource
en su código , quédese con$http
.Esta fue mi experiencia: comencé mi primer proyecto angular, necesitaba hacer solicitudes HTTP a una interfaz RESTful, así que hice la misma investigación que estás haciendo ahora. Basado en la discusión que leí en SO preguntas como esta, decidí seguir
$resource
. Esto fue un error que desearía poder deshacer. Este es el por qué:$http
Los ejemplos son abundantes, útiles y, en general, justo lo que necesita. Los$resource
ejemplos claros son escasos y (en mi experiencia) rara vez todo lo que necesita. Para el novato Angular, no se dará cuenta de las implicaciones de su elección hasta más tarde, cuando esté atrapado en la documentación y enojado porque no puede encontrar$resource
ejemplos útiles para ayudarlo.$http
es probablemente un mapa mental 1 a 1 de lo que estás buscando. No tiene que aprender un nuevo concepto para comprender con qué se encuentra$http
.$resource
trae muchos matices para los que aún no tienes un mapa mental.$http
devuelve una promesa y es.then
capaz, por lo que encaja perfectamente con las cosas nuevas que está aprendiendo sobre Angular y las promesas.$resource
, que no devuelve una promesa directamente, complica su comprensión tentativa de los fundamentos angulares.$resource
es potente porque condensa el código para llamadas RESTful CRUD y las transformaciones para entrada y salida. Eso es genial si estás cansado de escribir código repetidamente para procesar los resultados de$http
ti mismo. Para cualquier otra persona,$resource
agrega una capa críptica de sintaxis y paso de parámetros que es confusa.Ojalá me conociera hace 3 meses, y me estaría diciendo enfáticamente: "Quédate con un
$http
niño. Está bien".fuente
/user/:userId
o/thing
. Una vez que se muda a,/users/roles/:roleId
entonces tiene que modificar la url y los parámetros de $ resource por verbo y podría estar usando $ http en ese momento.$resource
y cambiar a$http
lugares. No puedo enfatizar lo suficiente cuánto desearía desear, desear nunca haber conocido$resource
. Probablemente he perdido más de una semana persiguiendo los matices de los$resource
últimos meses.$http
es tan fácil y directo, que cualquier ganancia que se pueda obtener$resource
fue completamente eliminada por la curva de aprendizaje.Creo que es importante enfatizar que $ resource espera un objeto o matriz como respuesta del servidor, no una cadena sin formato. Entonces, si tiene una cadena sin formato (o cualquier cosa, excepto el objeto y la matriz) como respuesta, debe usar $ http
fuente
Cuando se trata de elegir entre
$http
o$resource
técnicamente hablando, no hay una respuesta correcta o incorrecta en esencia, ambos harán lo mismo.El propósito de
$resource
es permitirle pasar una cadena de plantilla (una cadena que contiene marcadores de posición) junto con los valores de los parámetros.$resource
reemplazará los marcadores de posición de la cadena de plantilla con los valores de los parámetros que se pasan como un objeto. Esto es principalmente útil cuando interactúa con la fuente de datos RESTFul, ya que utilizan principios similares para definir las URL.Lo que
$http
hace es realizar las solicitudes HTTP asincrónicas.fuente
$resource
no se puede realizar de forma asincrónica? Solo quería aclarar$http
es la forma más simple de realizar solicitudes HTTP asincrónicas y lo que$resource
esencialmente hace lo mismo pero con diferentes parámetrosEl servicio de recursos es simplemente un servicio útil para trabajar con APSI REST. cuando lo usas no escribes tus métodos CRUD (crear, leer, actualizar y eliminar)
Por lo que veo, el servicio de recursos es solo un acceso directo, puede hacer cualquier cosa con el servicio http.
fuente
$http.get('/path/to/thing', params)
versusmyResource.get(params)
más, realmente haciendo la configuración paramyResource
. Más código por adelantado y solo funciona a la perfección con el mismo nombre API. De lo contrario, está codificando tanto como si usara $ http.Una cosa que noté al usar $ resource sobre $ http es si está utilizando API web en .net
$ resource está vinculado a un controlador que ejecuta un solo propósito.
$ resource ('/ user /: userId', {userId: '@ id'});
Mientras que $ http podría ser de cualquier cosa. solo especifica la url.
$ http.get - "api / authenticate"
Es solo mi opinión.
fuente
El servicio $ resource actualmente no admite promesas y, por lo tanto, tiene una interfaz claramente diferente al servicio $ http.
fuente
var myResource = $resource(...config...);
en otro lugar del servicio que hacesreturn myResource.get(..params...)
o puedes hacervar save = myResource.save(); save.$promise.then(...fn...); return save;