1. ¿Qué es una API REST?

Una API de transferencia de estado representacional (REST), o API de RESTful, es una interfaz
de programación de aplicaciones que se ajusta a los límites de la arquitectura REST.

Una API o interfaz de programación de aplicaciones es un conjunto de definiciones y

protocolos que se usa para diseñar e integrar el software de aplicaciones. Suele considerarse
como el contrato entre un proveedor de información y un usuario, donde se establece el
contenido que se requiere del consumidor (la llamada) y el que necesita el productor (la
respuesta).

Por ejemplo, una API de servicio meteorológico podría solicitar que el usuario escribiera un
código postal y que el productor diera una respuesta en dos partes: la primera sería la
temperatura máxima y la segunda, la mínima.

2. ¿Cuáles son los métodos de petición o verbos que define http?

Los métodos HTTP suelen ser verbos en inglés, por lo que también son comúnmente llamados
Verbos HTTP.

Cada Método HTTP implementa una semántica distinta, pero entre ellos comparten muchas
cosas.

Los métodos HTTP comúnmente usados son:

GET
El método GET solicita una representación de un recurso específico. Las peticiones que
usan el método GET sólo deben recuperar datos

POST
El método POST se utiliza para enviar una entidad a un recurso en específico, causando a
menudo un cambio en el estado o efectos secundarios en el servidor

PUT
El modo PUT reemplaza todas las representaciones actuales del recurso de destino con la
carga útil de la petición.

DELETE
El método DELETE borra un recurso en específico.

métodos que, aunque menos frecuentemente usados, es buena idea conocerlos Claro está
que estos no son los únicos métodos HTTP. También te podrás encontrar con los siguientes.

HEAD
El método HEAD pide una respuesta idéntica a la de una petición GET, pero sin el cuerpo
de la respuesta

CONNECT
 El método CONNECT establece un túnel hacia el servidor identificado por el recurso.

OPTIONS
El método OPTIONS es utilizado para describir las opciones de comunicación para el
recurso de destino

TRACE
El método TRACE realiza una prueba de bucle de retorno de mensaje a lo largo de la ruta
al recurso de destino.

PATCH
El método PATCH es utilizado para aplicar modificaciones parciales a un recurso.

3. ¿Definición y características principales de los lenguajes de intercambio de información

XML y JSON?

XML

XML es el acrónimo de Extensible Markup Language, es decir, es un lenguaje de marcado

que define un conjunto de reglas para la codificación de documentos.
El lenguaje de marcado es un conjunto de códigos que se pueden aplicar en el análisis de
datos o la lectura de textos creados por computadoras o personas. El lenguaje XML
proporciona una plataforma para definir elementos para crear un formato y generar un
lenguaje personalizado.
Un archivo XML se divide en dos partes: prolog y body. La parte prolog consiste en
metadatos administrativos, como declaración XML, instrucción de procesamiento
opcional, declaración de tipo de documento y comentarios. La parte del body se compone
de dos partes: estructural y de contenido (presente en los textos simples).
El diseño XML se centra en la simplicidad, la generalidad y la facilidad de uso y, por lo
tanto, se utiliza para varios servicios web. Tanto es así que hay sistemas destinados a
ayudar en la definición de lenguajes basados en XML, así como APIs que ayudan en el
procesamiento de datos XML – que no deben confundirse con HTML.
Características de XML
 El XML separa datos de HTML.
 XML simplifica el intercambio de datos.
 El XML aumenta la disponibilidad de datos
 El XML se puede utilizar para crear nuevos idiomas de Internet

JSON
SON, cuyo nombre corresponde a las siglas JavaScript Object Notation o Notación de
Objetos de JavaScript, es un formato ligero de intercambio de datos, que resulta sencillo
de leer y escribir para los programadores y simple de interpretar y generar para las
máquinas. Está basado en un subconjunto del Lenguaje de Programación JavaScript.
Características de JSON
 JSON es solo un formato de datos.
  Requiere usar comillas dobles para las cadenas y los nombres de propiedades. Las
comillas simples no son válidas.
 Una coma o dos puntos mal ubicados pueden producir que un archivo JSON no
funcione.
 Puede tomar la forma de cualquier tipo de datos que sea válido para ser incluido
en un JSON, no solo arreglos u objetos. Así, por ejemplo, una cadena o un número
único podrían ser objetos JSON válidos.
 A diferencia del código JavaScript, en el que las propiedades del objeto pueden no
estar entre comillas, en JSON solo las cadenas entre comillas pueden ser utilizadas
como propiedades.

4. ¿Cuáles son los tipos de datos disponibles en JSON y su sintaxis?

Los tipos de datos disponibles con JSON son:
Números: Se permiten números negativos y opcionalmente pueden contener
parte fraccional separada por puntos.
Ejemplo: 123.456
Cadenas: Representan secuencias de cero o más caracteres. Se ponen entre doble
comilla y se permiten cadenas de escape.
Ejemplo: "Hola"
Booleanos: Representan valores booleanos y pueden tener dos valores:
Ejemplo: true y false
Null: Representan el valor nulo.
Array: Representa una lista ordenada de cero o más valores los cuales pueden ser
de cualquier tipo. Los valores se separan por comas y el vector se mete entre
corchetes.
Ejemplo: ["juan","pedro","jacinto"]
Objetos: Son colecciones no ordenadas de pares de la forma <nombre>:<valor>
separados por comas y puestas entre llaves. El nombre tiene que ser una cadena
entre comillas dobles. El valor puede ser de cualquier tipo.
Ejemplo:
 5. ¿Cuáles son los códigos de respuestas de peticiones HTTP? (construir tabla con columnas
código y descripción)
Código
Respuestas informativas
100 Continue
101 Switching protocols
102 Processing (WebDAV; RFC 2518)
Peticiones correctas
200 OK
201 Created
202 Aceptada.
203 Non-Authoritative Information
204 No Content
205 Reset Content
206 Partial Content
207 Multi-Status (WebDAV; RFC 4918)
Redirecciones
300 Multiple Choices
Descripción
Este tipo de código de estado indica una respuesta
provisional. HTTP/1.0 no definió ningún estado 1XX, por lo
que los servidores no deberían enviar una respuesta 1XX a
un cliente HTTP/1.0 salvo para experimentos.
El servidor ha recibido los headers del request y el cliente
debería enviar el cuerpo de la respuesta.
El requester ha solicitado al servidor conmutar protocolos.
Usado en requests para reanudar peticiones PUT o POST
abortadas.
Este código de estado indica que la acción solicitada por el
cliente ha sido recibida, entendida, aceptada y procesada
correctamente.
El request es correcto. Esta es la respuesta estándar para
respuestas correctas.
El request se ha completado y se ha creado un nuevo
recurso.
El request se ha aceptado para procesarlo, pero el proceso
aún no ha terminado.
El request se ha procesado correctamente, pero devuelve
información que podría venir de otra fuente.
El request se ha procesado correctamente, pero no
devuelve ningún contenido.
El request se ha procesado correctamente, pero no
devuelve ningún contenido y se requiere que el requester
recargue el contenido.
El servidor devuelve sólo parte del recurso debido a una
limitación que ha configurado el cliente (se usa en
herramientas de descarga como wget).
El cuerpo del mensaje es XML y puede contener un
número de códigos de estado diferentes dependiendo del
número de sub-requests.
El cliente ha de tomar una acción adicional para completar
el request. Muchos de estos estados se utilizan para
redirecciones. El user-agent puede llevar a cabo la acción
adicional sin necesidad de que actúe el usuario sólo si el
método utilizado en la segunda petición es GET o HEAD. Un
user-agent no debería redireccionar automáticamente un
request más de cinco veces, ya que esas redirecciones
suelen indicar un infinite loop.
Es una lista de enlaces. El usuario puede seleccionar un
enlace e ir a esa dirección. Hay un máximo de cinco
direcciones.
 301 Moved Permanently
302 Found
303 See Other
304 Not Modified
305 Use Proxy (desde HTTP/1.1)
307 Temporary Redirect (desde HTTP/1.1)
308 Permanent Redirect (RFC 7538)
Errores del cliente
400 Bad Request
401 Unauthorized (RFC 7235)
402 Payment Required
403 Forbidden
404 Not Found
405 Method Not Allowed
406 Not Acceptable
407 Proxy Authentication Required (RFC
7235)
408 Request Timeout
La página solicitada se ha movido
permanentemente a una nueva URI.
La página solicitada se ha movido
temporalmente a una nueva URI.
La página solicitada se puede encontrar en una URI
diferente.
Indica que la página solicitada no se ha modificado desde
la última petición.
El recurso solicitado sólo está disponible a través de proxy,
cuya dirección se proporciona en la respuesta. Muchos
clientes HTTP como Mozilla o Internet Explorer no manejan
bien estas respuestas con estos códigos de estado, sobre
todo por seguridad.
La página solicitada se ha movido temporalmente a otra
URL. En este caso el recurso debería de repetirse con otra
URI, sin embargo, futuros requests deberán usar la URI
original. Al contrario que con la 302, el método request no
puede cambiar cuando se reubique el request original.
El request y futuros requests deberían repetirse usando
otro URI. Este también es similar al 301, pero no permite al
método HTTP que cambie.
Excepto cuando se responde a un HEAD request, el
servidor debe incluir una entidad que contiene una
explicación del error, y si es temporal o permanente. Son
aplicables a cualquier método de solicitud (GET, POST...).
Los user agents deben mostrar cualquier entidad al
usuario:
El servidor no puede o no va a procesar el request por un
error de sintaxis del cliente.
Similar al error 403, pero se usa cuando se requiere una
autentificación y ha fallado o todavía no se a facilitado.
Reservado para futuro uso. La intención original fue para
pago con tarjeta o micropago, pero eso no ha ocurrido, y
este código apenas se usa.
El request fue válido pero el servidor se niega a responder.
El recurso del request no se ha podido encontrar pero
podría estar disponible en el futuro. Se permiten requests
subsecuentes por parte del cliente.
Se ha hecho un request con un recurso usando un método
request no soportado por ese recurso (por ejemplo usando
GET en un formulario que requiere POST).
El recurso solicitado solo genera contenido no aceptado de
acuerdo con los headers Accept enviados en el request.
El cliente se debe identificar primero con el proxy.
El cliente no ha enviado un request con el tiempo
necesario con el que el servidor estaba preparado para

409 Conflict.
410 Gone
Errores del servidor
500 Internal Server Error
501 Not Implemented
502 Bad Gateway
503 Service Unavailable
504 Gateway Timeout
505 HTTP Version Not Supported
511 Network Authentication Required (RFC
6585)
esperar. El cliente podría repetir el request sin
modificaciones más tarde.
conflicto en el request, como cuando se actualizan al
mismo tiempo dos recursos.
El recurso solicitado no está disponible ni lo estará en el
futuro. Un buscador eliminará antes una página 410 que
una 404.
El servidor ha fallado al completar una solicitud
aparentemente válida. Cuando los códigos de estado
empiezan por 5 indica casos en los que el servidor sabe
que tiene un error o realmente es incapaz de procesar el
request. Salvo cuando se trata de un request HEAD, el
servidor debe incluir una entidad conteniendo una
explicación del error, y de si es temporal o permanente.
Igualmente los usar-agents deberán mostrar cualquier
entidad al usuario. Estos códigos de respuesta se aplican a
cualquier método request.
Error genérico, cuando se ha dado una condición no
esperada y no se puede concretar el mensaje.
El servidor o no reconoce el método del request o carece
de la capacidad para completarlo. Normalmente es algo
que se ofrecerá en el futuro, como un nuevo servicio de
una API.
El server actuaba como puerta de entrada o proxy y recibió
una respuesta inválida del servidor upstream.
El servidor está actualmente no disponible, ya sea por
mantenimiento o por sobrecarga.
El servidor estaba actuando como puerta de entrada o
proxy y no recibió una respuesta oportuna por parte del
servidor upstream.
El servidor no soporta la versión del protocolo HTTP usada
en el request.
El cliente necesita autentificarse para poder acceder a la
red.
6. ¿Qué es una cabecera HTTP?

Las Cabeceras HTTP son los parámetros que se envían en una petición o respuesta HTTP al
cliente o al servidor para proporcionar información esencial sobre la transacción en curso.
Estas cabeceras proporcionan información mediante la sintaxis 'Cabecera: Valor' y son
enviadas automáticamente por el navegador o el servidor Web.

7. ¿Cuándo se usan las cabeceras Accept, Authorization, Cookie, Content-Type?

Accept

La cabecera de pedido Accept anuncia que tipo de contenido el cliente puede procesar,
expresado como un tipo MIME. Usando negociación de contenido, el servidor selecciona una
de las propuestas, la utiliza e informa al cliente de la elección a través de la cabecera de
respuesta Content-Type.

Authorization

La cabecera de petición Authorization contiene las credenciales para autenticar a un usuario

en un servidor, usualmente luego de que el servidor haya respondido con un estado 401
Unauthorized y la cabecera WWW-Authenticate.

Cookie

La cabecera de respuesta HTTP Set-Cookie se usa para enviar cookies desde el servidor al
agente de usuario, así el agente de usuario puede enviarlos de vuelta al servidor.

Content-Type

Content-Type es la propiedad de cabecera (header) usada para indicar el media type del
recurso.

Content-Type dice al cliente que tipo de contenido será retornado. Los navegadores rastrearán
MIME en algunos casos y no necesariamente seguirán el valor de este encabezado; para evitar
este comportamiento, el encabezado X-Content-Type-Optionsse puede establecer en nosniff.

En solicitudes (tales como POST o PUT), el cliente indica al servidor que tipo de datos es
enviado actualmente.

8. ¿Qué es y cómo funciona JWT?

¿Qué es?

Un JSON Web Token es un token de acceso estandarizado en el RFC 7519 que permite el
intercambio seguro de datos entre dos partes. Contiene toda la información importante sobre
una entidad, lo que implica que no hace falta consultar una base de datos ni que la sesión
tenga que guardarse en el servidor (sesión sin estado).

Por este motivo, los JWT son especialmente populares en los procesos de autentificación. Con
este estándar es posible cifrar mensajes cortos, dotarlos de información sobre el remitente y
demostrar si este cuenta con los derechos de acceso requeridos. Los propios usuarios solo
entran en contacto con el token de manera indirecta: por ejemplo, al introducir el nombre de
usuario y la contraseña en una interfaz. La comunicación como tal entre las diferentes
aplicaciones se lleva a cabo en el lado del cliente y del servidor.

¿Como funciona el JWT?

El inicio de sesión de usuario ejemplifica bien la función del JSON Web Token. Antes de utilizar
el JWT, hay que establecer una clave secreta. Una vez que el usuario ha introducido
correctamente sus credenciales, el JWT se devuelve con la clave y se guarda localmente. La
transmisión debe realizarse a través de HTTPS para que los datos estén mejor protegidos.

De esta manera, cada vez que el usuario accede a recursos protegidos, como a una API o a una
ruta protegida, el user agent utiliza el JWT como parámetro (por ejemplo, JWT para peticiones
GET) o como header de autorización (para POST, PUT, OPTIONS y DELETE). La otra parte puede
descifrar el JSON Web Token y ejecutar la solicitud si la verificación se realiza correctamente.