Solicitud de API externa

¿No es demasiada teoría?

Pongamos esto en práctica. Vamos a abrir AppMaster, crear una solicitud de API utilizando, y obtener una mejor comprensión de cómo funciona esta solicitud.

Creación de una solicitud de API externa

Las solicitudes de API se crean en la sección "Lógica empresarial", en la pestaña "Solicitudes de API externas".

Es el momento de hacer clic en "+ Nueva solicitud de API".

El nombre y la descripción se pueden establecer con cualquier cosa, son sólo para nuestro uso personal.

Vamos a tratar los datos que realmente importan.

Lo mínimo necesario para crear una solicitud es especificar su Método y su dirección (URL). Empecemos por la última.

URL

URL - Localizador Uniforme de Recursos. Es la dirección que se da a un recurso concreto en Internet. La versión más conocida de un recurso de este tipo es una página HTML: introducimos su URL en la barra de direcciones del navegador y abrimos el sitio deseado. Al mismo tiempo, el recurso en sí puede ser cualquier cosa, una imagen, un vídeo, un conjunto de datos. Lo principal es que este recurso tiene un puntero específico - una URL a la que se puede enviar una solicitud para obtener este recurso.

Métodos

Al referirnos a los datos en su dirección, también indicamos el método (también se puede decir el tipo) de la solicitud, es decir, indicamos lo que realmente hay que hacer con estos datos.

Cuando enviamos peticiones para la tarea del primer módulo, recibimos datos. Este es el método GET. Este método es el más obvio y también el único requerido. Por lo tanto, aunque no lo hayamos especificado explícitamente, se asume por defecto que se trata de GET.

Veamos qué otros métodos existen.

El propio estándar HTTP no limita el número de métodos que se pueden utilizar. Al mismo tiempo, sólo algunos de los métodos más estándar se siguen utilizando para mantener la compatibilidad. Hay 5 métodos diferentes que se pueden utilizar en las solicitudes de la API de AppMaster.

GET. Ya se ha tratado. El método solicita el suministro de un recurso y recibe datos.

POST. Para tomar datos de algún lugar, primero hay que colocar estos datos allí. El método POST hace precisamente eso. Envía los datos al servidor y crea un recurso.

PUT. Similar al método POST, pero su trabajo es actualizar los datos. No crea nuevos datos, sino que reemplaza los datos existentes, los actualiza.

DELETE. Como su nombre indica, borra los datos.

PATCH. El método es similar a PUT, pero se utiliza para actualizar parcialmente los datos, en lugar de reemplazarlos por completo. Por ejemplo, utilizando el método PATCH, se puede cambiar el título de un artículo, o cambiar el valor de algún parámetro.

Es importante considerar el hecho de que el servidor no está obligado a hacer exactamente lo que se especifica en el método en absoluto. Podemos enviar la dirección de alguna página con el método DELETE, pero esto no significa que el servidor vaya a borrarla realmente. Pero, de forma puramente teórica, puede hacer esto con el comando GET. O no cambiar nada, pero al mismo tiempo enviar datos en respuesta a POST. Sólo porque el desarrollador lo configuró así.

Aquí es donde entra en juego REST, que dice que es el momento de ponerse de acuerdo en el cumplimiento de la orden, dejarse de líos y hacer exactamente lo que se indica en el método. Como mínimo, ésta debería ser la tarea principal (aunque no necesariamente la única). Por ejemplo, al transferir el contenido de un artículo mediante el método GET, se puede al mismo tiempo aumentar en 1 el contador del número de sus vistas.

Así pues, hemos averiguado dónde se encuentran los datos y qué se puede hacer con ellos. Vayamos más allá, veamos qué otros componentes puede tener la petición.

Parámetros de la URL

Parámetros de la URL. Hay situaciones en las que sólo conocemos parte de la URL. Un ejemplo son los artículos del sitio web Appmaster.io. La dirección inicial de todos los artículos es la misma: https: //appmaster.io/blog/. Pero luego cada artículo tiene su propio título y, en consecuencia, su propia parte individual para la indicación exacta de este artículo en particular.

En esta situación, se utilizan los parámetros de la URL. Prescribimos la parte general inmediatamente, y dejamos que el resto se decida en el proceso. Como resultado, la URL se escribe en la forma https://appmaster.io/blog/:id/

La parte conocida se escribe tal cual, y la parte variable se coloca después del signo ":". El nombre de esta parte variable (ya sin ":") se añade a la lista de parámetros. En este caso, puede haber varias partes variables, y su ubicación es cualquier lugar de la URL.

Parámetros de consulta

Parámetros de consulta. ¿Recuerdas cuando enviamos una petición a boredapi.com en el primer módulo? Y además de la dirección, se prescribieron datos adicionales. Eran los Query Params.

Se escriben después de la URL y están separados de ella por un signo "?". Se indica el nombre del parámetro, el signo "=" y el valor del propio parámetro. Si se utilizan varios parámetros a la vez, se separan con el signo "&".

Sin embargo, al especificar los parámetros en AppMaster, no tiene que pensar en las reglas de solicitud. Todo se formateará correctamente de forma automática. Sólo tiene que especificar el nombre del parámetro en sí y añadirlo a la lista.

Los parámetros de consulta se utilizan cuando la fuente de datos es la misma, pero los datos en sí pueden ser diferentes. Por ejemplo, Boredapi contenía una enorme lista de cosas por hacer. Pero a nosotros sólo nos interesan las que están destinadas a una persona y eso es lo que especificamos en los parámetros de la petición.

Otro caso de uso es limitar la cantidad de datos. Por ejemplo, podríamos acceder a alguna lista, pero solicitar sólo las 5 primeras entradas de la misma. Esta cantidad también puede ser un parámetro de consulta.

Otra opción es una clave de acceso. Es posible que haya utilizado esta opción en el módulo 1 al referirse a Alphavantage. Los datos podían obtenerse sólo después de registrarse y enviar una clave personal en los parámetros de consulta.

Preste atención a las páginas que visita en Internet, probablemente también encontrará varios parámetros en ellas. Por ejemplo, abra la página del tiempo de Ventusky.com, en los parámetros de consulta se envían los valores geográficos de latitud y longitud.

Cabeceras

Cabeceras. Cabeceras de solicitud. Normalmente las cabeceras contienen información de servicio sobre la solicitud (metainformación). Las cabeceras permiten al servidor obtener más información sobre el cliente que solicita los datos. Las cabeceras pueden contener información sobre qué navegador se está utilizando, en qué codificación se espera la respuesta, en qué idioma, la hora exacta de la solicitud, etc. En el caso de acceso a datos protegidos, las cabeceras pueden contener una clave de autorización.

En la mayoría de los casos, las cabeceras son opcionales. Incluso en el primer módulo, ya hicimos una petición en la que no especificamos ninguna cabecera (aunque esto no significa que la petición se enviara realmente sin ellas).

Cuerpo

Cuerpo. Cuerpo de la petición. Las peticiones GET suelen prescindir de él, pero si queremos enviar algún dato al servidor, enviar una petición POST o PUT, entonces estos datos se colocan en el cuerpo de la petición. Al mismo tiempo, se pueden colocar datos de cualquier complejidad en el cuerpo de la petición, por ejemplo, enviar un archivo de vídeo, y no limitarse a algún número o una cadena de texto.