- 1

Conexión a REST APIs con Angular HTTP y buenas prácticas
02:58 - 2

Solicitudes GET en APIs con Angular: Obtener Productos
10:41 - 3

Consulta de Producto Específico en eCommerce con Angular
11:31 - 4

Integración de Swiper en Angular para Galería de Productos
08:12 - 5

Creación de Productos con POST y Data Transfer Objects en Angular
15:59 - 6

Actualización de Datos con Métodos PUT y PATCH en APIs
14:23 - 7

Eliminar productos con solicitudes DELETE en Angular
06:04 - 8

Paginación de Productos con Parámetros URL en Angular
12:45 - 9

Ventajas de los Observables sobre Promesas en Angular
12:22 - 10

Implementación de Retry con Observadores en Angular
03:23
Uso de Contextos para Interceptores en Angular
Clase 20 de 23 • Curso de Consumo de APIs REST con Angular
Contenido del curso
- 11

Solución de Problemas CORS en Aplicaciones Angular
11:33 - 12

Gestión de Ambientes en Angular: Desarrollo vs Producción
05:06 - 13

Manejo de Errores en Observables con Angular
12:06 - 14

Transformaciones de Datos en el Frontend con Map y Pipes
06:02 - 15

Evitando el Callback Hell con SwitchMap y ZIP en Observables
10:42
- 16

Autenticación con JWT: Implementación y Gestión de Sesiones en APIs
19:43 - 17

Autenticación y Manejo de Tokens en Peticiones HTTP
09:31 - 18

Implementación de Interceptores en Angular para Medir Tiempos de Respuesta
08:03 - 19

Interceptores en Angular: Agregar Token Automáticamente
15:04 - 20

Uso de Contextos para Interceptores en Angular
05:50
Suele ocurrir que un front-end consume más de un backend diferente, con diferentes URLs, que eventualmente podrían utilizar diferentes tokens o necesitar cada uno de una manipulación diferente de la request por parte del interceptor.
Manipulando múltiples tipos de solicitudes
Es posible crear un contexto para los interceptores para indicar si queremos que X endpoint sea interceptado o no.
1. Importando clases necesarias
Para esto, importando HttpContextToken y HttpContext desde @angular/common/http vamos a crear una función para validar si el endpoint necesita o no la inyección de un token.
// interceptors/token-interceptor.interceptor.ts
import { HttpContextToken, HttpContext } from '@angular/common/http';
const ADD_TOKEN = new HttpContextToken<boolean>(() => true);
export function addToken() {
return new HttpContext().set(ADD_TOKEN, false);
}
Creamos la constante ADD_TOKEN que indicará si el endpoint necesita de un token o no. Por defecto, todos los endpoints necesitan un token. La función addToken() hará que no se inyecte el token cuando no se requiere.
También puedes utilizar la lógica inversa, que ningún endpoint por defecto utilice el token y solo habilitar manualmente los que si lo requieren.
2. Creando el contexto para las solicitudes
En la lógica del interceptor, colocamos un IF para validar si la petición necesita o no del token.
// interceptors/token-interceptor.interceptor.ts
intercept(request: HttpRequest<any>, next: HttpHandler): Observable<HttpEvent<unknown>> {
if (request.context.get(ADD_TOKEN)) {
request = this.addHeaders(request);
return next.handle(request);
} else
return next.handle(request);
}
3. Denegar la utilización del token
Ahora, importamos dicha función y la utilizamos para que un endpoint no requiera del token.
// services/auth.service.ts
import { addToken } from '../interceptors/token-interceptor.interceptor';
@Injectable({
providedIn: 'root'
})
export class AuthService {
constructor(private http: HttpClient) { }
loginUser(credentials: Credentials): Observable<Login> {
return this.http.post<Login>(`https://example.com/api/login`, credentials, { context: addToken() });
}
}
Agregamos como argumento context a las opciones de la solicitud. El endpoint de Login no suele necesitar de un token para funcionar, es el único que excluimos del uso del interceptor.
Contribución creada por: Kevin Fiorentino.