La solicitudes GET suelen utilizarse tanto para obtener un conjunto de registros, como para obtener uno solo. A continuación conocerás más sobre el proceso para crear una aplicación.
Cómo obtener un producto por ID
Cuando necesites obtener datos de un registro individual a través de su ID, el endpoint correspondiente para la petición suele recibir esa información como parte de su URL, por ejemplo https://example.com/api/producto/12, para obtener el producto con ID 12.
No es del todo una buena práctica que un endpoint GET reciba datos por medio de un body. Es posible, pero no recomendable y no es natural en una API Rest. Tenlo en cuenta si eres tú quien desarrolla el backend también.
En el servicio para realizar las peticiones HTTP, el método getProduct() recibe el ID como parámetro para concatenarlo a la URL.
Simulando una API
Si no tienes a disposición una API real para construir tu App, puedes simular peticiones HTTP en Angular con lo que se conoce como mock de datos. Un objeto que mantiene la estructura de datos real que tendrá la información de tu aplicación.
// services/api.service.tsimport{Observable,of}from'rxjs';@Injectable({providedIn:'root'})exportclassApiService{constructor(privatehttp:HttpClient,){}getProduct(idProduct: string):Observable<Product>{returnof({id:1,name:'Automobil de juguete',precio:100,image:'https://static3.depositphotos.com/1000865/118/i/600/depositphotos_1183767-stock-photo-toy-car.jpg'});}}
Utilizando la función of importándola desde RxJS, esta función convierte lo que sea que le envíes como parámetro, en un observable.
De esta manera, tu componente recibirá la respuesta del observable como si fuese una API real que responde datos para construir tu aplicación.
Contribución creada por: Kevin Fiorentino.
Consulta de Producto Específico en eCommerce con Angular
Interesante como ejercicio, sin embargo en la practica el componente products habia previamente traido toda la información en el metodo ngOnInit cuando inicia la aplicación. Por tanto hay una alternativva a la implementación del metodo onShowDetail:
no creo que siempre e bien visto mandar a llamar servicios cuando ya tienes la informacion de producto en en cache solo es enviarle al event todo el obj ya que al final es la misma informacion que vas atener a menos que los eso depende de las reglas de negocio pero eres buen profesor algo despistado pero vamos bien..
Eso dependerá del API. Hay casos donde ocurre lo que dices, pero hay también otros casos donde la información entregada por el endpoint de listado de productos es limitada en comparación con la información entregada por el endpoint de detalle del producto. Es posible que el producto tenga demasiada información y no se muestre toda en el listado. En estos casos, y si el requerimiento lo exige, sí será necesario hacer una petición al detalle del producto para mostrar la información adicional que no se posea y el curso sencillamente tiene en cuenta esos casos. Es cuestión de analizar los requerimientos y el comportamiento del API y determinar la estrategia por usar. Si vas a llamar despistado a alguien, asegúrate de tener bien fundamentados los argumentos y usar una mejor redacción.
Entiendo que para practicar con las peticiones hacemos uso del servicio y pedimos solo el producto teniendo el ID, pero quisiera saber si pasar el producto hacia el padre y usarlo en vez de hacer uso del servicio es menos costoso.
En el caso particular de este ejemplo quizás si aplique lo que dices, ya que tanto el endpoint de todos los productos como el de detalle retorna la misma información, pero en escenarios más reales, en los endpoints que retornen listados de información no tendrás la misma información que cuando consultes el detalle de un ítem en especifico.
Lo normal es que en la API de todos los productos debería llegar información básica y en la API de detalle del producto debe llegar información muy especifica de un producto, por este motivo siempre se deben de configurar independientemente.
Hola, por ejemplo el onShowDetail, veo que le pones el mismo nombre al output (onShowDetail) que a la función en el padre (onShowDetail). Pero en otros casos veo que no haces coincidir el nombre. Si bien no es necesario q coincidan me parece más facil de ver. ¿Es una buena prácitca que coincidan? o recomiendas que no?
Saludos y espero haber sido claro.
Consulta para los mas experimentados. Es mas eficiente en terminos de preformance que haga una nueva consulta a la API teniendo previamente un array de los productos?
Está indicando que es una mala práctica utilizar el método GET para recibir datos que deberían estar en el cuerpo de la solicitud, ya que los parámetros GET se incluyen en la URL y pueden quedar expuestos públicamente, lo que podría ser un problema de seguridad si se trata de datos sensibles o privados. En cambio, se recomienda utilizar métodos como POST o PUT para enviar datos a través del cuerpo de la solicitud, donde los datos no son visibles en la URL y, por lo tanto, son más seguros y adecuados para ciertos tipos de información.
O.. puedes tratar de configurar la entrada de teclado si estas en Windows. abajo a la derecha seleccionas que use el "Espanol (Colombia), Teclado Latinoamerica y ahi quedara listo para obtenerlo oprimiendo alt gr + la tecla donde esta este simbolo "}"
Esto es más de Typescript, pero una buena práctica para indicar que un método va a recibir el' id' (o cualquier propiedad) de un modelo que hayamos definido, en lugar de decir:
get(id: string){// code...}
Pudiéramos tipar el 'id' (o parámetro que vayamos a recibir) usando el mismo modelo, indicando la propiedad que queremos usar de la siguiente manera:
get(id:Product['id']){// code...}
Así, Typescript obtendrá el tipado de esa propiedad que está definida en nuestro modelo, y si en algún momento debemos cambiar el tipado de la propiedad, solo lo cambiaríamos en la interfaz y automáticamente los métodos que hacen referencia a esa propiedad se actualizarán. Sin necesidad de ir a cambiar el tipo en cada método donde la estemos usando.