Min 2:46
Conceptos fundamentales
¿Qué es una API REST?
Flujo de comunicación entre usuarios, frontend y backend
Primeros pasos con fetch
Consume tu primera API REST
Endpoints y query parameters
¿Qué son los HTTP Status Codes?
¿Qué es una API KEY?
Proyecto
Maquetación del proyecto
¿Qué son los Métodos HTTP?
GET: leyendo michis favoritos
POST: guardando michis favoritos
Consultas a la API para escribir HTML dinámico
DELETE: borrando michis favoritos
Headers en peticiones HTTP
¿Qué son los Headers HTTP?
Header de autorización
Header de Content-Type
FormData: publicando imágenes de michis
Bonus
Axios: librerÃas de JavaScript para consumir APIs
CORS, caché, redirect y tu propio clon de fetch
GraphQL, Web Sockets y Web 3.0: el mundo más allá de REST
Próximos pasos
Toma el Curso Práctico de Consumo de API REST con JavaScript
Aún no tienes acceso a esta clase
Crea una cuenta y continúa viendo este curso
Aportes 4
Preguntas 0
Min 2:46
¿Que es MIME Types?
Los MIME Types (Multipurpose Internet Mail Extensions)
(Extenciones de correos de Intenet Multiproposito).
Son la manera standard de mandar contenido a través de la red. Los tipos MIME especifican tipos de datos, como por ejemplo texto, imagen, audio, etc. que los archivos contienen. Recuerde que debe utilizar el sufijo correcto para este tipo de archivo.
MIME adjunta a cada archivo un archivo de cabecera donde se indica el tipo y el subtipo del contenido de los datos del archivo. Gracias a esta información tanto el servidor como el navegador pueden manejar y presentar los archivos correctamente. Éstas no son las únicas ventajas: el usuario puede combinar archivos de distintos tipos de datos; se pueden incluir, por ejemplo, archivos de imágenes y de sonido en un documento HTML.
Para que MIME funcione correctamente, se debe utilizar la designación de nombres correcta.
Uno de los headers que determinaremos al enviar datos es el Content Type, es decir, que tipo de dato será lo que enviaremos, para que el backend pueda decir: Ah! Me están enviando un tipo de dato X, entonces debo leer el body de esta manera.
Tenemos muchÃsimos tipos de content types, empecemos a citarlos y agruparlos por categorÃas para que sea más fácil la lectura:
-Application: {
application/json,
application/xml,
application/zip,
application/x-www-form-urlencoded: "para enviar datos de formularios HTML"
}
EnvÃo de archivos de audio literalmente
-Audio: {
audio/mpeg,
audio/x-ms-wma,
audio/vnd.rn-realaudio,
audio/w-wav
}
-Image: {
image/gif,
image/jpeg,
image/png,
image/x-icon,
image/svg+xml
}
Video: {
video/mpeg,
video/mp4,
video/quicktime,
video/webm
}
Multipart: {
multipart/mixed,
multipart/alternative,
multipart/related,
multipart/form-data: "sirve para enviar datos de formularios, nos ahorra tener que hacer un querySelector a cada input y su value, al usar este tipo de dato podemos agrupar todos esos datos en uno solo"
}
Text: {
text/css,
text/csv,
text/html,
text/plain,
text/xml
}
VND: {
application/vnd.ms-excel,
application/vnd.ms-powerpoint,
application/msword
}
Más info: https://developer.mozilla.org/en-US/docs/Web/HTTP/Basics_of_HTTP/MIME_types/Common_types
Diferencia entre application/xml y text/xml
<?xml version="1.0" encoding="UTF-8"?>
esta sentencia puede ser ignorada cuando se usa text/xml. por lo que deberÃas pasar esa información en el propio header y generar muchos inconvenientes que pueden ser solucionados al usar application/xml.
Sin embargo, text/xml pareciera ser mejor para seguir la semántica de lectura humana.(siempre recordando enviar el encoding en el header)
Si un documento XML es legible para usuarios, es preferible text/xml a application/xml. Los agentes de usuario MIME que no tienen soporte explÃcito para text/xml lo tratarán como texto sin formato.
Si el conjunto de caracteres predeterminado (US-ASCII) para text/xml no es soportado, application/xml proporciona una alternativa
En resumen, application/xml es el preferido por sus ventajas, pero text/xml tiene sus respectivas aplicaciones.
¿Quieres ver más aportes, preguntas y respuestas de la comunidad? Crea una cuenta o inicia sesión.