javascript - query - npm angularjs resource

AngularJS $ http y $ resource

Question

Tengo algunos servicios web que quiero llamar. $resource o $http , ¿cuál debería 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 por favor explicarme en inglés simple 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?

Answer 1

Creo que es importante enfatizar que $ resource espera un objeto o una matriz como respuesta del servidor, no de una cadena en bruto. Por lo tanto, si tiene una cadena en bruto (o cualquier cosa, excepto el objeto y la matriz) como respuesta, debe usar $ http

Answer 2

Creo que la respuesta depende más de quién eres en el momento en que escribes el código. Use $http si es nuevo en Angular, hasta que sepa por qué necesita $resource . Hasta que tenga experiencia concreta de cómo $http está frenando, y comprende las implicaciones de usar $resource en su código , quédese con $http .

Esta fue mi experiencia: comencé mi primer proyecto Angular, necesitaba realizar solicitudes HTTP a una interfaz REST, por lo que hice la misma investigación que está haciendo ahora. Basado en la discusión que leí en SO preguntas como esta, elegí ir con $resource . Este fue un error que desearía poder deshacer. Este es el por qué:

1. $http ejemplos de $http son abundantes, útiles y, en general, solo lo que necesita. Los ejemplos claros $resource son escasos y (en mi experiencia) rara vez todo lo que necesita. Para el novato de Angular, no se dará cuenta de las implicaciones de su elección hasta más adelante, cuando esté atorado con la documentación y enojado porque no puede encontrar ejemplos de $resource útiles para ayudarlo.
2. $http es probablemente un mapa mental 1-a-1 de lo que estás buscando. No tiene que aprender un nuevo concepto para entender lo que obtiene con $http . $resource trae consigo muchos matices por los que aún no tienes un mapa mental.
3. Vaya, ¿dije que no tienes que aprender un nuevo concepto? Como novato en Angular , tienes que aprender acerca de las promesas. $http devuelve una promesa y es .then capaz, por lo que encaja perfectamente con las nuevas cosas que estás aprendiendo sobre Angular y promesas. $resource , que no devuelve una promesa directamente, complica su comprensión tentativa sobre los fundamentos angulares.
4. $resource es poderoso porque condensa el código para llamadas CRUD RESTful 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 confuso.

Ojalá me conociera hace 3 meses y me estaría diciendo enfáticamente: "Quédate con $http kid. Está bien".

Answer 3

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 la plantilla con los valores de los parámetros que se pasan como un objeto. Esto es útil sobre todo cuando se interactúa con el origen de datos RESTFul, ya que utilizan principios similares para definir las URL.

Lo que $http hace es realizar las solicitudes HTTP asíncronas.

Answer 4

El servicio $ resource actualmente no admite promesas y, por lo tanto, tiene una interfaz distinta al servicio $ http.

Answer 5

El servicio de recursos es un servicio útil para trabajar con APSI de 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.

Answer 6

Siento que otras respuestas, aunque son correctas, no explican del todo la raíz de la pregunta: REST es un subconjunto de HTTP . Esto significa que todo lo que se puede hacer a través de REST se puede hacer a través de HTTP pero no todo lo que se puede hacer a través de HTTP se puede hacer a través de REST . Es por eso que $resource usa $http internamente.

Entonces, ¿cuándo usarnos?

Si todo lo que necesita es REST , es decir, está intentando acceder a un RESTful web RESTful , $resource hará que sea muy fácil interactuar con ese servicio web.

Si, por el contrario, intenta acceder a CUALQUIER COSA que no sea un RESTful web de RESTful , tendrá que ir con $http . Tenga en cuenta que también puede acceder a un RESTful web RESTful través de $http , simplemente será mucho más incómodo que con $resource . Esta es la forma en que la mayoría de las personas lo han estado haciendo fuera de AngularJS, utilizando jQuery.ajax (equivalente a $http de Angular).

Answer 7

Una cosa que noté cuando uso $ resource over $ http es si está usando la API web en .net

$ resource está vinculado a un controlador que ejecuta un solo propósito.

$ resource (''/ user /: userId'', {userId: ''@ id''});

[HttpGet]
public bool Get(int id)
{
    return "value"
}

public void Post([FromBody]string value)
{
}

public void Put(int id, [FromBody]string value)
{
}

public void Delete(int id)
{
}

Mientras que $ http podría ser de cualquier cosa. sólo tiene que especificar la url.

$ http.get - "api / authenticate"

[HttpGet]
public bool Authenticate(string email, string password)
{
    return _authenticationService.LogIn(email, password, false);
}

Es solo mi opinión.

Answer 8

$http es para fines generales AJAX. En la mayoría de los casos esto es lo que vas a usar. Con $http , realizarás llamadas de tipo GET , POST , DELETE forma manual y procesando los objetos que devuelven por tu cuenta.

$resource wraps $http para usar en escenarios de API web RESTful.

Hablando MUY en general: un servicio web RESTful será un servicio con un punto final para un tipo de datos que hace diferentes cosas con ese tipo de datos basado en métodos HTTP como GET , POST , PUT , DELETE , etc. Así que con un $resource , puede llame a GET para obtener el recurso como un objeto JavaScript, luego modifíquelo y envíelo de vuelta con un POST , o incluso elimínelo con DELETE .

... Si eso tiene sentido.

Answer 9

$http realiza una llamada AJAX de propósito general, en la que generalmente significa que puede incluir una API RESTful más una API no RESTful .

y $resource está especializado para esa parte RESTful .

El Api en reposo llegó a prevalecer en los últimos años porque la url está mejor organizada en lugar de url aleatoria compuesta por programadores.

Si utilizo una API RESTful para construir la url, sería algo como /api/cars/:carId .

$resource forma de recuperar datos

angular.module(''myApp'', [''ngResource''])

    // Service
    .factory(''FooService'', [''$resource'', function($resource) {
        return $resource(''/api/cars/:carId'')
    }]);

    // Controller
    .controller(''MainController'', [''FooService'', function(FooService){
        var self = this;
        self.cars = FooService.query();
        self.myCar = FooService.get(''123'');

    }]);

Esto le dará un https://docs.angularjs.org/api/ngResource/service/$resource , que se acompaña de métodos de get , save , query , remove y delete automática.

$http forma de recuperar datos

angular.module(''myApp'', [])

    // Service
    .factory(''FooService'', [''$http'', function($http){
        return {
            query: function(){
                return $http.get(''/api/cars'');
            },

            get: function(){
                return $http.get(''/api/cars/123'');
            }
            // etc...
        }

Vea cómo necesitamos definir cada operación común en la API RESTFul . También una diferencia es que $http devuelve la promise mientras que $resource devuelve un objeto. También hay complementos de terceros para ayudar a Angular a lidiar con la API restangular como restangular

Si la API es algo como /api/getcarsinfo . Todo lo que nos queda es usar $http .