WEB Protocols Flashcards

Question 1

Q

¿Qué diferencias hay entre los métodos HTTP GET y POST?

Answer

A

GET
- Envía datos en la URL
- Tiene límites de longitud
- Es menos seguro (datos visibles)
- Ideal para consultar datos
- Puede ser almacenado en caché
- Puede ser marcado como favorito
- Es idempotente (repetible sin efectos secundarios)
POST
- Envía datos en el cuerpo de la petición
- No tiene límite práctico de datos
- Es más seguro (datos no visibles en la URL)
- Usado para enviar o modificar datos
- No se almacena en caché
- No se puede marcar como favorito
- No siempre es idempotente

Question 2

Q

¿Qué significa que HTTP es stateless? ¿Qué implicancias tiene eso para el frontend?

Answer

A

HTTP es stateless significa que cada petición es independiente y el servidor no guarda información del estado del cliente entre peticiones.

Implicancias para el frontend:
- El frontend debe enviar toda la información necesaria en cada petición.
- Se usan cookies, tokens o sesiones para mantener el estado del usuario (como autenticación).
- Mayor responsabilidad en el manejo de estado en el cliente o mediante servicios externos (como almacenamiento local o global state).

Question 3

Q

¿Qué es un código de estado 200/201/204/400/401/403/404/500 y cuándo los has visto?

Answer

A

Códigos de estado HTTP:

200 OK: Petición exitosa. Visto al cargar una página correctamente.
201 Created: Recurso creado. Usado al enviar un formulario con POST.
204 No Content: Petición exitosa, sin respuesta. Visto tras borrar algo.
400 Bad Request: Error del cliente (sintaxis inválida). Visto en formularios mal enviados.
401 Unauthorized: Falta autenticación. Visto sin token o login.
403 Forbidden: Acceso denegado. Visto al intentar acceder a recursos sin permiso.
404 Not Found: Recurso no encontrado. Visto en URLs mal escritas.
500 Internal Server Error: Error en el servidor. Visto cuando algo falla en backend.

¿Cuándo los has visto?
En desarrollo web (red de DevTools) o navegando páginas rotas o protegidas.

Question 4

Q

¿Qué son los headers HTTP? Menciona algunos comunes.

Answer

A

Headers HTTP son campos clave-valor enviados en las solicitudes y respuestas HTTP. Transmiten metadatos como tipo de contenido, autenticación o control de caché.

en el header de un http hay:
un contento tipo que tiene una app con jason statham,
statham lo autoriza con un token que dice “accept”, un user-agent faja a statham y aparece el cacho con un radiocontrol y se come una cookie

Ejemplos comunes:

Content-Type: Tipo de contenido (ej. application/json)
Authorization: Token de acceso o credenciales
Accept: Tipo de respuesta esperada (ej. application/json)
User-Agent: Info del navegador/cliente
Cache-Control: Instrucciones de almacenamiento en caché
Set-Cookie: Enviar cookies al cliente

Question 5

Q

¿Qué es Content-Type y Accept? ¿Por qué son importantes?

Answer

A

Content-Type indica el tipo de contenido enviado en una solicitud o respuesta (ej. application/json, text/html).
Accept indica el tipo de contenido que el cliente espera recibir.

Importancia:
- Aseguran que servidor y cliente se entiendan (formato correcto).
- Evitan errores de interpretación de datos.
- Son claves en APIs para intercambiar JSON, XML, etc.

Question 6

Q

¿Qué es una API RESTful?

Answer

A

Una API RESTful es una interfaz que sigue los principios de REST (Representational State Transfer) para permitir comunicación entre sistemas usando HTTP.

Características clave:
- Usa métodos HTTP: GET, POST, PUT, DELETE
- Accede a recursos mediante URLs
- Sin estado (stateless)
- Intercambia datos en formato como JSON o XML
- Respuestas con códigos de estado HTTP

Ejemplo:
GET /usuarios/1 → devuelve datos del usuario con ID 1.
Stateless significa que el servidor no guarda información del estado del cliente entre peticiones.

Cada solicitud debe contener toda la información necesaria (ej. tokens, parámetros), ya que el servidor no “recuerda” solicitudes anteriores.

Question 7

Q

¿Cómo interactúas desde el frontend con una API? fetch

Answer

A

Desde el frontend se interactúa con una API usando solicitudes HTTP, típicamente con fetch, axios u otras librerías.

Pasos comunes:
1. Elegir método HTTP (GET, POST, etc.)
2. Especificar URL de la API
3. Incluir headers (Content-Type, Authorization, etc.)
4. Enviar datos (en el body si aplica)
5. Procesar la respuesta (ej. JSON)

Ejemplo con fetch:
```javascript
fetch(‘https://api.example.com/usuarios’, {
method: ‘GET’,
headers: { ‘Authorization’: ‘Bearer token’ }
})
.then(res => res.json())
.then(data => console.log(data))

Question 8

Q

¿Cómo interactúas desde el frontend con una API usando Axios?

Answer

A

Axios es una librería de JavaScript para hacer solicitudes HTTP desde el frontend (o Node.js), más sencilla que fetch.

Ejemplo básico:
```javascript
import axios from ‘axios’;

axios.get(‘https://api.example.com/usuarios’, {
headers: { Authorization: ‘Bearer token’ }
})
.then(res => console.log(res.data))
.catch(err => console.error(err));

Ventajas:

Sintaxis más simple que fetch

Manejo automático de JSON

Soporte para interceptores, timeouts y más

Question 9

Q

¿Cómo manejarías paginación en una API desde el cliente?

Answer

A

La paginación en una API permite dividir los resultados en páginas para manejar grandes volúmenes de datos.

Pasos para manejar paginación desde el cliente:

Solicitud inicial:
Enviar una solicitud a la API especificando parámetros de paginación (ej. page, limit, offset).Ejemplo con fetch:
```javascript
fetch(‘https://api.example.com/items?page=1&limit=10’)
.then(res => res.json())
.then(data => {
console.log(data.items); // Mostramos los datos de la página
});

Question 10

Q

¿Qué es CORS y cómo afecta al frontend?

Answer

A

CORS (Cross-Origin Resource Sharing) es un mecanismo de seguridad que restringe cómo los recursos de un servidor pueden ser solicitados desde dominios diferentes.

¿Cómo afecta al frontend?
- Si tu frontend intenta hacer una solicitud a una API en otro dominio (origen cruzado), el navegador verifica las cabeceras CORS de la respuesta.
- Si el servidor no permite el acceso desde el dominio del frontend, el navegador bloquea la solicitud.

Soluciones comunes:
- El servidor debe incluir el encabezado Access-Control-Allow-Origin para permitir solicitudes desde dominios específicos.
- Si el servidor es externo, se puede utilizar un proxy o configurar CORS en el servidor si es posible.

Ejemplo de cabecera CORS:
```http
Access-Control-Allow-Origin: https://mi-frontend.com

Question 11

Q

¿Qué métodos de autenticación has usado en APIs (API Key, JWT, OAuth)?

Answer

A

Métodos de autenticación comunes en APIs:

API Key:
- Una clave única asignada al cliente que se incluye en cada solicitud.
- Se pasa generalmente en los headers o como parámetro de URL.
- Ventaja: Fácil de usar.
- Desventaja: Menos seguro que otros métodos, ya que puede ser interceptado si no se usa HTTPS.
JWT (JSON Web Token):
- Un token seguro que se genera tras una autenticación exitosa (login).
- Se incluye en los headers de cada solicitud subsecuente para verificar la identidad del usuario.
- Ventaja: Escalable y no requiere guardar sesiones en el servidor.
- Desventaja: Necesita ser almacenado y gestionado correctamente (ej. en almacenamiento local).
OAuth:
- Un protocolo que permite que los usuarios den acceso a sus datos sin compartir sus credenciales directamente.
- Usado por servicios como Google, Facebook, etc., para permitir el acceso a sus APIs.
- Ventaja: Proporciona acceso granular y controlado.
- Desventaja: Más complejo de implementar debido a sus múltiples flujos (Authorization Code, Implicit Flow, etc.).

¿Cuándo usarlos?
- API Key: Para servicios simples o acceso limitado.
- JWT: Para autenticación moderna en aplicaciones SPA (Single Page Application).
- OAuth: Cuando se necesita delegar autenticación a un tercero, como Google o Facebook.

Question 12

Q

¿Qué es rate limiting y cómo te puede afectar como frontend?

Answer

A

Rate limiting es una técnica utilizada para controlar la cantidad de solicitudes que un cliente puede realizar a un servidor en un período de tiempo determinado.

¿Cómo funciona?
- El servidor establece un límite en la cantidad de solicitudes que un cliente puede hacer (ej. 100 solicitudes por minuto).
- Si el cliente supera el límite, el servidor devuelve un error (generalmente 429 Too Many Requests).

¿Cómo afecta al frontend?
- Restricción en la cantidad de solicitudes: Si haces demasiadas solicitudes en poco tiempo, podrías encontrar bloqueos temporales o fallos en la carga de datos.
- Manejo de errores: El frontend debe gestionar respuestas de error (429) y manejar adecuadamente la situación, como mostrar un mensaje de espera o intentar de nuevo después.
- Optimización de solicitudes: Se debe implementar estrategias como caché, agrupación de solicitudes o peticiones condicionales para reducir la frecuencia de llamadas.

Ejemplo de respuesta de rate limiting:
```http
HTTP/1.1 429 Too Many Requests
Retry-After: 60

Question 13

Q

¿Cómo optimizas el rendimiento cuando consumes APIs (debounce, caching, SWR, etc.)?

Answer

A

Técnicas para optimizar el rendimiento al consumir APIs:

Debounce:
Retrasar solicitudes para evitar demasiadas peticiones en corto tiempo. Útil en búsquedas en tiempo real.
Ejemplo: Usar debounce de lodash en eventos de entrada.
Caching:
Guardar los resultados de la API para evitar solicitudes repetidas.
Ejemplo: Usar localStorage o sessionStorage para almacenar datos.
SWR (Stale-While-Revalidate):
Mostrar datos antiguos mientras se obtienen nuevos.
Ejemplo: Usar bibliotecas como SWR o React Query.
Batching (Agrupación de solicitudes):
Agrupar varias solicitudes en una sola para reducir la sobrecarga de red.
Rate Limiting:
Limitar la frecuencia de solicitudes para evitar la sobrecarga del servidor y bloqueos.

Ventajas:
- Mejora la experiencia de usuario.
- Reduce la carga en el servidor.
- Optimiza el uso de red y almacenamiento.

Question 14

Q

¿Qué es Vue Query y cómo se usa para consumir APIs?

Answer

A

Vue Query es una librería para gestionar el estado de datos asíncronos en aplicaciones Vue, simplificando la obtención, almacenamiento y sincronización de datos.

Características principales:
- Automatización de peticiones: Hace fetch de datos de manera sencilla y eficiente.
- Cacheo de datos: Guarda los resultados para evitar solicitudes repetidas.
- Sincronización: Actualiza los datos en segundo plano.
- Manejo de errores y reintentos: Automáticamente maneja errores y reintenta solicitudes fallidas.

Ejemplo básico:
```javascript
import { useQuery } from ‘vue-query’;

export default {
setup() {
const { data, error, isLoading } = useQuery(‘items’, () =>
fetch(‘https://api.example.com/items’).then((res) => res.json())
);

return { data, error, isLoading };   } };

Question 15

Q

¿Cómo gestionas el estado de las respuestas de una API? (Ej: loading, error, success)

Answer

A

Para gestionar el estado de las respuestas de una API, se suele manejar al menos tres estados: loading, error y success.

Loading (Cargando):
Se activa cuando se está esperando la respuesta de la API.
Ejemplo: Mostrar un spinner o mensaje de “Cargando…”.
Error (Error):
Se activa si la solicitud falla, por ejemplo, si hay un problema de red o la API devuelve un error.
Ejemplo: Mostrar un mensaje de error como “Hubo un problema al cargar los datos”.
Success (Exitoso):
Se activa cuando la solicitud se completa con éxito y los datos se reciben correctamente.
Ejemplo: Mostrar los datos obtenidos de la API en la interfaz.

WEB Protocols Flashcards

(15 cards)