En este artículo, hablaremos de cuáles son los métodos de solicitud API/HTTP y cómo utilizarlos. Veremos las razones para utilizar un método de petición HTTP como GET, POST, PUT y otros. Los temas que cubriremos en este post son los siguientes:

• Protocolo HTTP
• Arquitectura cliente-servidor
• APIs

¿Qué es el HTTP?

HTTP es un protocolo, o un conjunto definido de reglas, para acceder a recursos en la web. Los recursos pueden ser cualquier cosa, desde archivos HTML hasta datos de una base de datos, fotos, texto, etc. Estos recursos se ponen a nuestra disposición a través de una API y nosotros hacemos peticiones a estas APIs a través del protocolo HTTP. API significa interfaz de programación de aplicaciones. Es el mecanismo que permite a los desarrolladores solicitar recursos.

Arquitectura cliente-servidor

Para entender los métodos HTTP, es importante cubrir el concepto de arquitectura cliente/servidor, la arquitectura describe cómo funcionan todas las aplicaciones web y las reglas de cómo se comunican.

Una aplicación cliente es la parte con la que el usuario interactúa y es la que muestra el contenido. Por otro lado, una aplicación servidor es la que envía el contenido o recurso, a su aplicación cliente. Ésta se ejecuta en el backend y está continuamente escuchando y esperando una petición. La razón principal de esta separación es asegurar la información sensible y la eficiencia. Podemos considerar que toda la aplicación cliente se descarga en el navegador, y todos los datos pueden ser accedidos por cualquiera que acceda a tu página web. Esta arquitectura ayuda a proteger cosas como las claves de la API, los datos personales, etc. Ahora, herramientas modernas como Next.js y Netlify permiten a los desarrolladores ejecutar código de servidor en la misma aplicación que su aplicación cliente, sin necesidad de una aplicación de servidor dedicada.

Comunicación cliente-servidor

Las aplicaciones cliente y servidor se comunican mediante el envío de mensajes individuales en función de las necesidades, en lugar de un flujo continuo de comunicación. Estas comunicaciones son casi siempre iniciadas por los clientes en forma de solicitudes. Estas peticiones son atendidas por la aplicación servidor, que devuelve una respuesta con el recurso solicitado, entre otras cosas.

Por qué necesitamos una arquitectura servidor-cliente

Digamos que estás construyendo una aplicación web del tiempo, por ejemplo. La aplicación meteorológica con la que el usuario va a interactuar es la aplicación cliente: tiene botones, una barra de búsqueda y muestra datos como el nombre de la ciudad, la temperatura actual, el AQI, etc.

Esta aplicación meteorológica no tendría cada ciudad y su información meteorológica codificada directamente en ella. Esto haría que la aplicación se hinchara y fuera lenta, llevaría una eternidad investigar y añadir manualmente a una base de datos, y sería un dolor de cabeza actualizarla cada día.

En su lugar, la aplicación puede acceder a los datos meteorológicos por ciudad utilizando la API web del tiempo. Tu aplicación recogería la ubicación de tu usuario y luego haría una petición al servidor diciendo: “Oye, envíame la información meteorológica de esta ciudad específica”.

Dependiendo de lo que se quiera conseguir, se utilizarían los distintos métodos de solicitud disponibles. El servidor devuelve una respuesta con la información meteorológica y algunas otras cosas, dependiendo de cómo esté escrita la API. También puede devolver cosas como una marca de tiempo, la región en la que se encuentra esta ciudad, etc.

Su aplicación cliente se comunica con una aplicación servidor que se ejecuta en algún lugar, cuyo único trabajo es escuchar continuamente una solicitud a esa dirección. Cuando recibe una solicitud, trabaja para satisfacerla, ya sea leyendo de una base de datos, de otra API, de un archivo local o de un cálculo programático basado en los datos que le pasas.

La anatomía de una solicitud HTTP

Una petición HTTP debe tener lo siguiente:

• Un método HTTP (comoGET)
• Una URL de acogida (comohttps://api.spotify.com/)
• Una ruta de acceso a un punto final (comov1/artists/{id}/related-artists)

Una solicitud también puede tener opcionalmente:

• Cuerpo
• Cabeceras
• Cadenas de consulta
• Versión HTTP

La anatomía de una respuesta HTTP

La respuesta debe tener lo siguiente:

• Versión del protocolo (comoHTTP/1.1)
• Código de estado (como200)
• Texto de estado (OK)
• Cabeceras

Una respuesta también puede tener opcionalmente:

• Cuerpo

Explicación de los métodos HTTP

Ahora que sabemos qué es HTTP y por qué se utiliza, vamos a hablar de los diferentes métodos que tenemos a nuestra disposición.

En el ejemplo de la aplicación meteorológica anterior, queríamos recuperar información meteorológica sobre una ciudad. Pero, ¿qué pasaría si quisiéramos enviar información meteorológica de una ciudad?

En la vida real, probablemente no tendrías permisos para alterar los datos de otra persona, pero imaginemos que somos colaboradores de una aplicación meteorológica gestionada por la comunidad. Y además de obtener la información meteorológica de una API, los miembros de esa ciudad podrían actualizar esta información para mostrar datos más precisos.

¿O qué pasaría si quisiéramos añadir una nueva ciudad que, por alguna razón, no existiera ya en nuestra base de datos de ciudades? Todas estas son funciones diferentes -recuperar datos, actualizar datos, crear nuevos datos- y hay métodos HTTP para todas ellas.

Peticiones HTTP POST

Utilizamos POST para crear un nuevo recurso. Una petición POST requiere un cuerpo en el que se definen los datos de la entidad a crear. requires a body in which you define the data of the entity to be created.

Una solicitud POST exitosa sería un código de respuesta 200. En nuestra aplicación meteorológica, podríamos utilizar un método POST para añadir datos meteorológicos sobre una nueva ciudad.

Peticiones HTTP GET

Utilizamos GET para leer o recuperar un recurso. Un GET exitoso devuelve una respuesta que contiene la información solicitada.

En nuestra aplicación meteorológica, podríamos utilizar un GET para recuperar el tiempo actual de una ciudad concreta.

Peticiones HTTP PUT

Utilizamos PUT para modificar un recurso. PUT actualiza todo el recurso con los datos que se pasan en el cuerpo de la carga útil. Si no hay ningún recurso que coincida con la solicitud, creará un nuevo recurso.

En nuestra aplicación meteorológica, podríamos utilizar PUT para actualizar todos los datos meteorológicos de una ciudad concreta.

Peticiones HTTP PATCH

Utilizamos PATCH para modificar una parte de un recurso. Con PATCH, sólo tienes que pasar los datos que quieres actualizar.

En nuestra aplicación meteorológica, podríamos utilizar PATCH para actualizar las precipitaciones de un día concreto en una ciudad determinada.

Peticiones HTTP DELETE

Utilizamos DELETE para eliminar un recurso. En nuestra aplicación meteorológica, podríamos utilizar DELETE para eliminar una ciudad que ya no queramos rastrear por alguna razón.

Preguntas frecuentes sobre el método HTTP

¿Cuál es la diferencia entre PUT y POST?

Las peticiones PUT son idempotentes, lo que significa que la ejecución de la misma petición PUT producirá siempre el mismo resultado.

Por otro lado, un POST producirá diferentes resultados. Si ejecutas una petición POST varias veces, crearás un nuevo recurso varias veces a pesar de tener los mismos datos pasados.

Utilizando una analogía con un restaurante, si se realiza una solicitud POST varias veces se crearán varios pedidos distintos, mientras que si se realizan varias solicitudes PUT se actualizará el mismo pedido existente.

¿Cuál es la diferencia entre PUT y PATCH?

Las principales diferencias son que PUT creará un nuevo recurso si no encuentra el recurso especificado. Y con PUT hay que pasar los datos para actualizar todo el recurso, aunque sólo se quiera modificar un campo.

Con PATCH, puedes actualizar parte de un recurso simplemente pasando los datos del campo a actualizar.

¿Y si sólo quiero actualizar una parte de mi recurso? ¿Puedo seguir utilizando PUT?

Si sólo quieres actualizar una parte de tu recurso, aún tienes que enviar los datos de todo el recurso cuando hagas una petición PUT. La opción más adecuada en este caso sería PATCH.

¿Por qué el cuerpo es opcional para una solicitud y una respuesta?

Un cuerpo es opcional porque para algunas solicitudes, como las recuperaciones de recursos utilizando el método GET, no hay nada que especificar en el cuerpo de su solicitud. Usted está solicitando todos los datos del punto final especificado.

Del mismo modo, un cuerpo es opcional para algunas respuestas cuando un código de estado es suficiente o no hay nada que especificar en el cuerpo, por ejemplo con una operación DELETE.

Ejemplos de solicitudes HTTP

Ahora que hemos cubierto lo que es una solicitud HTTP, y por qué las usamos, ¡vamos a hacer algunas solicitudes! Vamos a jugar con la API Gist de GitHub.

“Gist es una forma sencilla de compartir fragmentos y pegados con otros. Todos los Gist son repositorios Git, por lo que son automáticamente versionados, forkables y utilizables desde Git.” (Fuente: Github)

Para ello necesitarás una cuenta de GitHub. Si aún no tienes una, esta es una gran oportunidad para empezar una para guardar tu código en el futuro.

Todos los usuarios de GitHub pueden crear gists, recuperar sus gists, recuperar todos los gists públicos, eliminar un gist y actualizar un gist, entre otras cosas. Para mantener las cosas sencillas utilizaremos Hoppscotch, una plataforma con una bonita interfaz utilizada para hacer peticiones HTTP de forma rápida y sencilla.

• Hay un menú desplegable en el que puede seleccionar el método con el que desea crear una solicitud.
• Hay un cuadro de texto donde debe pegar la URL del punto final de la API al que desea acceder.

• Hay una sección de cabeceras donde pasaremos las cabeceras según las instrucciones de los documentos de GitHub.

• Hay un área de cuerpo donde pasaremos el contenido a nuestro cuerpo como se indica en los documentos de GitHub.

• La columna de la derecha le permitirá saber rápidamente si su solicitud fue exitosa. Si está en verde, ha realizado su solicitud con éxito, y si está en rojo ha habido un error.

Cómo hacer una solicitud GET

Para hacer una petición GET para recuperar todos los gists de un usuario específico, podemos utilizar el siguiente método y endpoint: GET /usuarios/{nombredeusuario}/gists. La documentación nos indica los parámetros que podemos pasar para realizar esta petición.

Vemos que en la ruta tenemos que pasar una cadena con el nombre de usuario de destino. También vemos que tenemos que pasar una cabecera llamada accept y ponerla como application/vnd.github.v3+json.

Nos dan la URL de esta API:

https://api.github.com

Nos dan la ruta del punto final para esta operación específica:

/usuarios/{nombre de usuario}/gists

Para hacer esta petición:

1. Pegue la URL completa + la ruta en el campo de entrada de Hoppscotch. Asegúrate de reemplazar el nombre de usuario con un nombre de usuario real. Si no tienes un GitHub con Gists existentes, puedes usar el mío: camiinthisthang.
2. Seleccione el método de solicitud GET
3. En la pestaña de cabeceras, establezca accept como cabecera y defina el valor como application/vnd.github.v3+jsonapplication/vnd.github.v3+json

4. ¡Dale a enviar!

En la parte inferior, verás tu respuesta formateada como JSON. Para leer esto con más claridad, copie la respuesta y péguela en un formateador JSON en línea.

En el formateador, podrás ver que la respuesta es una matriz de objetos. Cada objeto representa un gist, mostrándonos información como la URL, el ID, etc.

Cómo hacer una solicitud POST

Ahora vamos a crear un recurso utilizando el método POST. En este contexto, el nuevo recurso sería un nuevo gist.

Primero tendremos que crear un token de acceso personal. Para ello, ve a tu página de configuración y pulsa Generar token.

Nombra tu token y selecciona el ámbito “Crear Gists”:

A continuación, haga clic en el botón verde Generar ficha en la parte inferior de la página.

Copie su código de acceso y péguelo en algún lugar donde pueda recuperarlo fácilmente.

Ahora estamos listos para hacer nuestra petición. La documentación nos dice que debemos pasar una cabecera, y un objeto files en el cuerpo. Opcionalmente podemos pasar algunas otras cosas, incluyendo un booleano que dicta si este gist es público o privado.

Nos dan la URL de esta API:

https://api.github.com

Nos dan la ruta del punto final para esta operación específica:

/gists

Para hacer esta solicitud:

1. Pegue la URL completa + la ruta en el campo de entrada de Hoppscotch.
2. Seleccione el método de solicitud POST
3. En la pestaña Cabeceras, establece accept como cabecera y establece el valor a application/vnd.github.v3+json
4. En la pestaña Body, establece el tipo de contenido a application/json. A continuación, empezaremos con un objeto {}. Dentro de este objeto, estableceremos el booleano público a true. Luego definiremos la propiedad files, y el valor es otro objeto con una clave del nombre de tu nuevo gist. El valor para esto debe ser otro objeto cuya clave es el contenido.

El valor aquí debería ser lo que quieras añadir realmente al gist.Aquí está el código para que puedas copiar/pegar:

{
  "public": true, 
  "files": {
    "postgist.txt": {
      "content": "Adding a GIST via the API!!"
    }
  }
}

5. En la pestaña de Autorización, establece el tipo de autorización como Basic Auth. Escribe tu nombre de usuario de Github y pasa tu token de acceso personal que hemos creado en el campo de la contraseña.

Después de ejecutar esto, obtenemos una respuesta larga. Una forma fácil de comprobar que tu gist fue creado es ir a tus Gists en GitHub.

¡Vemos que hemos añadido con éxito un Gist!

Cómo hacer una solicitud de PATCH

Vamos a actualizar el título y la descripción del Gist que acabamos de crear. Recuerde: PATCH permite actualizar una parte de un recurso, no todo el recurso. Todo lo que no pasemos no se modificará.

En realidad no pasamos una descripción a nuestro Gist cuando lo creamos, así que podemos parchearlo y crear una.

Nos dan la URL de esta API:

https://api.github.com

Nos dan la ruta del punto final para esta operación específica:

/gists/{gist_id}

Para hacer esta solicitud:

1. Pegue la URL completa + la ruta en el campo de entrada de Hoppscotch. Obtenga el Gist ID del gist que desea actualizar. Puedes encontrar el ID yendo al Gist en GitHub y copiando la cadena alfanumérica al final de la URL.

2.  Seleccione el método de solicitud PATCH.

3.  En la pestaña de cabeceras, establece accept como cabecera y fija el valor a application/vnd.github.v3+json.

4.  En la pestaña Autorización, establece el tipo de autorización como Basic Auth. Escribe tu nombre de usuario de GitHub y pasa tu token de acceso personal que hemos creado en el campo de la contraseña.

5.  En la pestaña Cuerpo, pasaremos la descripción y el título actualizados. Aquí está el código:

{
  "description": "Adding a description via the API", 
  "files": {
    "postgist.txt": {
      "content": "Adding a GIST via the API!! -- adding this line at the end to make the content slightly longer"
    }
  }
}

Si refrescamos nuestro Gist, vemos que tenemos un título y una descripción actualizados.

Cómo hacer una solicitud de DELTE

Vamos a eliminar el Gist que hemos creado. Debemos pasar la cabecera y el ID del Gist.

Nos dan la URL de esta API:

https://api.github.com

Nos dan la ruta del punto final para esta operación específica:

/gists/{gist_id}

Para hacer esta solicitud:

1. Pegue la URL completa + la ruta en el campo de entrada de Hoppscotch. Obtenga el Gist ID del gist que desea actualizar. Puedes encontrar el ID yendo al Gist en GitHub y copiando la cadena alfanumérica al final de la URL.

2.  Seleccione el método de solicitud DELETE

3. En la pestaña de Cabeceras, ponemos accept como cabecera y establecemos el valor a application/vnd.github.v3+json.

Si navegamos a nuestras Gists, vemos que ésta no existe y eliminamos el recurso con éxito.

Cómo hacer peticiones en su aplicación

Usamos Hoppscotch porque nos permite hacer peticiones rápidamente sin tener que girar toda una aplicación o descargar nada.

Si quisieras hacer peticiones en una aplicación JavaScript/React, podrías usar Javascript fetch o Axios.

Gracias por considerar este artículo, esperamos que haya sido lo suficientemente interesante.