Geekly articles weekly

Automatización para los más pequeños. Notas API RESTful

Este artículo es una de las notas cortas prometidas durante la serie de artículos Automation For The Smallest .
Dado que la forma principal de interactuar con el sistema IPAM es la API RESTful, decidí hablar de ello por separado.


Elogio a los arquitectos del mundo moderno: tenemos interfaces estandarizadas. Sí, hay muchos de ellos, esto es un inconveniente, pero lo son, es un plus.

Estas interfaces se han ganado el nombre de API - Interfaz de programación de aplicaciones.

Una de estas interfaces es la API RESTful, que se utiliza para trabajar con NetBox.



Si es muy simple, entonces la API le brinda al cliente un conjunto de herramientas a través de las cuales puede administrar el servidor. Y el cliente puede ser esencialmente cualquier cosa: un navegador web, una consola de comandos, una aplicación desarrollada por el fabricante o cualquier otra aplicación que tenga acceso a la API.

Por ejemplo, en el caso de NetBox, puede agregarle un nuevo dispositivo de las siguientes maneras: a través de un navegador web, enviando curl'om una solicitud en la consola, use Postman, acceda a la biblioteca de solicitudes en python, use el SDK de pynetbox o vaya a Swagger.

Por lo tanto, una vez que ha escrito una única interfaz, el fabricante se libera para siempre de la necesidad de acordar con cada nuevo cliente cómo conectarla (aunque esto es solo un poco astuto).

Contenido


  • REST, RESTful, API
  • Estructura de mensajes HTTP
    • Línea de inicio
    • Encabezados
    • El cuerpo del mensaje HTTP

  • Métodos
    • HTTP GET
    • HTTP POST
    • HTTP PUT
    • PARCHE HTTP
    • HTTP DELETE

  • Formas de trabajar con la API RESTful
    • Rizo
    • Cartero
    • Python + Solicitudes
    • Pynebtbox SDK
    • Swagger

  • Críticas a REST y alternativas
  • Enlaces utiles

REST, RESTful, API


A continuación daré una descripción muy simplificada de lo que es REST.

Para empezar, la API RESTful es exactamente la interfaz de interacción basada en REST, mientras que REST ( REpresentational State Transfer ) es un conjunto de restricciones utilizadas para crear servicios WEB.

Es posible leer exactamente qué limitaciones se pueden encontrar en el Capítulo 5 de la disertación de Roy Fielding, los estilos arquitectónicos y el diseño de arquitecturas de software basadas en red . Déjame darte solo los tres más significativos (desde mi punto de vista):

  1. La arquitectura REST utiliza el modelo de interacción Cliente-Servidor.
  2. Cada solicitud REST contiene toda la información necesaria para su ejecución. Es decir, el servidor no debe recordar nada sobre solicitudes de clientes anteriores, que, como usted sabe, se caracteriza por la palabra Sin estado: no almacene información de estado.
  3. Interfaz unificada La implementación de la aplicación es independiente del servicio que proporciona. Es decir, el usuario sabe lo que hace y cómo interactuar con él, pero no importa cómo lo hace. Cuando cambia la aplicación, la interfaz permanece igual y los clientes no necesitan ajustarse.

Los servicios WEB que satisfacen todos los principios de REST se denominan servicios RESTful WEB .

Y la API que proporciona servicios RESTful WEB se llama RESTful API.

REST no es un protocolo, sino el llamado estilo de arquitectura (uno de). Desarrollado con HTTP por Roy Fielding, REST estaba destinado a utilizar HTTP 1.1 como transporte.

Dirección de destino (o en otras palabras, un objeto, o de otra manera, un punto final): este es nuestro URI habitual.

El formato de los datos transmitidos es XML o JSON .
Para esta serie de artículos sobre linkmeup, se implementó una implementación de solo lectura (para ustedes, queridos lectores). Instalación de NetBox: netbox.linkmeup.ru : 45127.

No se requieren derechos de lectura, pero si desea intentar leer con un token, puede usar esto: API de token: 90a22967d0bc4bdcd8ca47ec490bbf0b0cb2d9c8 .
Hagamos una solicitud de diversión:

curl -X GET -H "Authorization: TOKEN 90a22967d0bc4bdcd8ca47ec490bbf0b0cb2d9c8" \ -H "Accept: application/json; indent=4" \ http://netbox.linkmeup.ru:45127/api/dcim/devices/1/

Es decir, con la utilidad curl , creamos un objeto GET en netbox.linkmeup.ru : 45127 / api / dcim / devices / 1 / con una respuesta JSON y una sangría de 4 espacios.

O un poco más académicamente: GET devuelve el objeto de dispositivos escritos, que es un parámetro del objeto DCIM .

También puede cumplir con esta solicitud, simplemente cópiela en su terminal.
La URL a la que nos referimos en la solicitud se llama Endpoint . En cierto sentido, este es el objeto final con el que interactuaremos.
Por ejemplo, en el caso de netbox, aquí se puede obtener una lista de todos los puntos finales.
Y preste atención al signo / al final de la URL: es obligatorio .
Esto es lo que obtenemos en respuesta:

 { "id": 1, "name": "mlg-host-0", "display_name": "mlg-host-0", "device_type": { "id": 4, "url": "http://netbox.linkmeup.ru/api/dcim/device-types/4/", "manufacturer": { "id": 4, "url": "http://netbox.linkmeup.ru/api/dcim/manufacturers/4/", "name": "Hypermacro", "slug": "hypermacro" }, "model": "Server", "slug": "server", "display_name": "Hypermacro Server" }, "device_role": { "id": 1, "url": "http://netbox.linkmeup.ru/api/dcim/device-roles/1/", "name": "Server", "slug": "server" }, "tenant": null, "platform": null, "serial": "", "asset_tag": null, "site": { "id": 6, "url": "http://netbox.linkmeup.ru/api/dcim/sites/6/", "name": "", "slug": "mlg" }, "rack": { "id": 1, "url": "http://netbox.linkmeup.ru/api/dcim/racks/1/", "name": "A", "display_name": "A" }, "position": 41, "face": { "value": "front", "label": "Front", "id": 0 }, "parent_device": null, "status": { "value": "active", "label": "Active", "id": 1 }, "primary_ip": null, "primary_ip4": null, "primary_ip6": null, "cluster": null, "virtual_chassis": null, "vc_position": null, "vc_priority": null, "comments": "", "local_context_data": null, "tags": [], "custom_fields": {}, "config_context": {}, "created": "2020-01-14", "last_updated": "2020-01-14T18:39:01.288081Z" }

Este es JSON (como solicitamos), que describe el dispositivo con ID 1: cómo se llama, con qué rol, qué modelo, dónde se encuentra, etc.

Esto se verá como una solicitud HTTP:

  GET /api/dcim/devices/1/ HTTP/1.1 Host: netbox.linkmeup.ru:45127 User-Agent: curl/7.54.0 Accept: application/json; indent=4


Entonces la respuesta se verá:
  HTTP/1.1 200 OK Server: nginx/1.14.0 (Ubuntu) Date: Tue, 21 Jan 2020 15:14:22 GMT Content-Type: application/json Content-Length: 1638 Connection: keep-alive Data

Volcar la transacción .

Ahora descubramos lo que hemos hecho.


Estructura de mensajes HTTP


Un mensaje HTTP consta de tres partes, de las cuales solo se requiere la primera.

  • Línea de inicio
  • Encabezados
  • Cuerpo del mensaje

Línea de inicio


Las líneas de inicio de la solicitud y respuesta HTTP se ven diferentes.

Solicitud HTTP


 METHOD URI HTTP_VERSION

El método determina qué acción quiere realizar el cliente: recibir datos, crear un objeto, actualizarlo, eliminarlo.
URI : el identificador del recurso donde el cliente accede, o en otras palabras, la ruta al recurso / documento.
HTTP_VERSION es la versión HTTP, respectivamente. Hoy, para REST, siempre es 1.1.
Un ejemplo:

 GET /api/dcim/devices/1/ HTTP/1.1


Respuesta HTTP


 HTTP_VERSION STATUS_CODE REASON_PHRASE

HTTP_VERSION : versión HTTP (1.1).
STATUS_CODE : tres dígitos del código de estado (200, 404, 502, etc.)
REASON_PHRASE - Explicación (OK, NO ENCONTRADO, MALA PUERTA DE ENLACE, etc.)

Un ejemplo:

 HTTP/1.1 200 OK

Encabezados


Los encabezados pasan los parámetros para esta transacción HTTP.

Por ejemplo, en el ejemplo anterior en la solicitud HTTP, estos fueron:

  Host: netbox.linkmeup.ru:45127 User-Agent: curl/7.54.0 Accept: application/json; indent=4

Indican que

  1. Pasamos al host netbox.linkmeup.ru:45127 ,
  2. La solicitud se generó en curl ,
  3. Y aceptamos datos en formato JSON con sangría de 4 .

Y aquí están los encabezados en la respuesta HTTP:

  Server: nginx/1.14.0 (Ubuntu) Date: Tue, 21 Jan 2020 15:14:22 GMT Content-Type: application/json Content-Length: 1638 Connection: keep-alive

Indican que

  1. Tipo de servidor: nginx en Ubuntu ,
  2. Tiempo de respuesta
  3. Formato de datos de respuesta: JSON
  4. Longitud de datos de respuesta: 1638 bytes
  5. No es necesario cerrar la conexión; todavía habrá datos.

Los encabezados, como ya ha notado, se ven como pares nombre: valor, separados por un signo ":".

Una lista completa de posibles encabezados .

El cuerpo del mensaje HTTP


El cuerpo se utiliza para transferir los datos reales.

En la respuesta HTTP, puede ser una página HTML o, en nuestro caso, un objeto JSON.

Debe haber al menos una línea en blanco entre los encabezados y el cuerpo.

Cuando se utiliza el método GET en una solicitud HTTP, generalmente no hay cuerpo porque no hay nada que transmitir. Pero el cuerpo está en la respuesta HTTP.

Pero, por ejemplo, con POST, el cuerpo ya estará en la solicitud. Hablemos de los métodos y hablemos ahora.


Métodos


Como ya entendió, HTTP utiliza métodos para trabajar con servicios WEB. Lo mismo ocurre con la API RESTful.

Los posibles escenarios de la vida real se describen con el término CRUD: Crear, Leer, Actualizar, Eliminar .
Aquí hay una lista de los métodos HTTP más populares que implementan CRUD:

  • HTTP GET
  • HTTP POST
  • HTTP PUT
  • HTTP DELETE
  • PARCHE HTTP

Los métodos también se llaman verbos , porque indican qué acción se realiza.

Lista completa de métodos .

Veamos cada uno de ellos usando el ejemplo de NetBox.

HTTP GET


Este es un método para obtener información.

Entonces, por ejemplo, quitamos la lista de dispositivos:

 curl -H "Accept: application/json; indent=4" \ http://netbox.linkmeup.ru:45127/api/dcim/devices/

El método GET es seguro porque no cambia los datos, solo pregunta.

Es idempotente desde el punto de vista que la misma consulta siempre devuelve el mismo resultado (hasta que los datos en sí mismos hayan cambiado).

En GET, el servidor devuelve un mensaje con el código HTTP y el cuerpo de respuesta ( código de respuesta y cuerpo de respuesta ).

Es decir, si todo está bien, entonces el código de respuesta es 200 (OK).
Si no se encuentra la URL, 404 (NO ENCONTRADO).
Si algo está mal con el servidor o los componentes, puede ser 500 (ERROR DEL SERVIDOR) o 502 (MALA PUERTA DE ENLACE).
Todos los posibles códigos de respuesta .

El cuerpo se devuelve en formato JSON o XML.

Volcar la transacción .

Demos un par de ejemplos más. Ahora solicitaremos información sobre un dispositivo específico por su nombre.

 curl -X GET -H "Accept: application/json; indent=4" \ "http://netbox.linkmeup.ru:45127/api/dcim/devices/?name=mlg-leaf-0"

Aquí, para establecer las condiciones de búsqueda en el URI, también especifiqué el atributo del objeto (el parámetro de nombre y su valor mlg-leaf-0 ). Como puede ver, antes de la condición y después de la barra hay un "?" , y el nombre y el valor están separados por un signo "=" .

Así es como se ve la solicitud.

  GET /api/dcim/devices/?name=mlg-leaf-0 HTTP/1.1 Host: netbox.linkmeup.ru:45127 User-Agent: curl/7.54.0 Accept: application/json; indent=4

Volcar la transacción .

Si necesita especificar un par de condiciones, la consulta se verá así:

 curl -X GET -H "Accept: application/json; indent=4" \ "http://netbox.linkmeup.ru:45127/api/dcim/devices/?role=leaf&site=mlg"

Aquí solicitamos todos los dispositivos de hoja ubicados en el sitio web mlg .
Es decir, las dos condiciones están separadas entre sí por el signo "&" .

Volcar la transacción .

Desde lo curioso y agradable: si a través de "&" establece dos condiciones con el mismo nombre, entonces entre ellas no habrá un "Y" lógico, sino un "OR" lógico.

Es decir, tal consulta en realidad devolverá dos objetos: mlg-leaf-0 y mlg-spine-0

 curl -X GET -H "Accept: application/json; indent=4" \ "http://netbox.linkmeup.ru:45127/api/dcim/devices/?name=mlg-leaf-0&name=mlg-spine-0"

Volcar la transacción .

Intentemos acceder a una URL inexistente.

 curl -X GET -H "Accept: application/json; indent=4" \ "http://netbox.linkmeup.ru:45127/api/dcim/IDGAF/"

Volcar la transacción .


HTTP POST


POST se utiliza para crear un nuevo objeto en una colección de objetos. O en un lenguaje más complejo: crear un nuevo recurso subordinado.

Aclaración de arthuriantech :
Incluyendo, pero no limitado a. El método POST está diseñado para transferir datos al servidor para su posterior procesamiento; se utiliza para cualquier acción que no necesite ser estandarizada dentro de HTTP. Antes de RFC 5789, era la única forma legal de hacer cambios parciales.
roy.gbiv.com/untangled/2009/it-is-okay-to-use-post
tools.ietf.org/html/rfc7231#section-4.3.3


Es decir, si hay un conjunto de dispositivos, POST le permite crear un nuevo objeto de dispositivo dentro de los dispositivos.

Seleccione el mismo Endpoint y use POST para crear un nuevo dispositivo.

 curl -X POST "http://netbox.linkmeup.ru:45127/api/dcim/devices/" \ -H "accept: application/json"\ -H "Content-Type: application/json" \ -H "Authorization: TOKEN a9aae70d65c928a554f9a038b9d4703a1583594f" \ -d "{ \"name\": \"just a simple russian girl\", \"device_type\": 1, \"device_role\": 1, \"site\": 3, \"rack\": 3, \"position\": 5, \"face\": \"front\"}"

Aquí aparece un encabezado de Autorización , que contiene un token que autoriza la solicitud de escritura, y después de la directiva -d hay JSON con los parámetros del dispositivo creado:

 { "name": "just a simple russian girl", "device_type": 1, "device_role": 1, "site": 3, "rack": 3, "position": 5, "face": "front"}

Su solicitud no funcionará porque el token ya no es válido; no intente escribir en NetBox.
La respuesta viene con una respuesta HTTP con el código 201 (CREADO) y JSON en el cuerpo del mensaje, donde el servidor devuelve todos los parámetros sobre el dispositivo creado.

  HTTP/1.1 201 Created Server: nginx/1.14.0 (Ubuntu) Date: Sat, 18 Jan 2020 11:00:22 GMT Content-Type: application/json Content-Length: 1123 Connection: keep-alive JSON

Volcar la transacción .

Ahora, con una nueva solicitud con el método GET, puede verla en la salida:

 curl -X GET -H "Accept: application/json; indent=4" \ "http://netbox.linkmeup.ru:45127/api/dcim/devices/?q=russian"

"Q" en NetBox le permite encontrar todos los objetos que contienen en su nombre una línea que va más allá.
POST, obviamente, no es seguro ni idempotente : probablemente cambia los datos, y una solicitud ejecutada dos veces conducirá a la creación del segundo mismo objeto o a un error.


HTTP PUT


Este es un método para modificar un objeto existente. El punto final para PUT se ve diferente que para POST: ahora contiene un objeto específico.

PUT puede devolver los códigos 201 o 200.

Un punto importante con este método: debe pasar todos los atributos requeridos, ya que PUT reemplaza el objeto antiguo.

Por lo tanto, si, por ejemplo, solo intentamos agregar el atributo asset_tag a nuestro nuevo dispositivo, obtenemos un error:

 curl -X PUT "http://netbox.linkmeup.ru:45127/api/dcim/devices/18/" \ -H "accept: application/json" \ -H "Content-Type: application/json" \ -H "Authorization: TOKEN a9aae70d65c928a554f9a038b9d4703a1583594f" \ -d "{ \"asset_tag\": \"12345678\"}" 

 {"device_type":["This field is required."],"device_role":["This field is required."],"site":["This field is required."]}

Pero si agrega los campos faltantes, entonces todo funcionará:

 curl -X PUT "http://netbox.linkmeup.ru:45127/api/dcim/devices/18/" \ -H "accept: application/json" \ -H "Content-Type: application/json" \ -H "Authorization: TOKEN a9aae70d65c928a554f9a038b9d4703a1583594f" \ -d "{ \"name\": \"just a simple russian girl\", \"device_type\": 1, \"device_role\": 1, \"site\": 3, \"rack\": 3, \"position\": 5, \"face\": \"front\", \"asset_tag\": \"12345678\"}"

Volcar la transacción .
Preste atención a la URL aquí: ahora incluye la ID del dispositivo que queremos cambiar ( 18 ).


PARCHE HTTP


Este método se utiliza para modificar parcialmente el recurso.
Wat? Usted pregunta, pero ¿qué pasa con PUT?

PUT es un método que originalmente existía en el estándar, que implica el reemplazo completo de un objeto mutable. En consecuencia, en el método PUT, como escribí anteriormente, tendrá que especificar incluso aquellos atributos del objeto que no cambian.

Y PATCH se agregó más tarde y le permite especificar solo aquellos atributos que realmente cambian.

Por ejemplo:

 curl -X PATCH "http://netbox.linkmeup.ru:45127/api/dcim/devices/18/" \ -H "accept: application/json" \ -H "Content-Type: application/json" \ -H "Authorization: TOKEN a9aae70d65c928a554f9a038b9d4703a1583594f" \ -d "{ \"serial\": \"BREAKINGBAD\"}"

Aquí, la ID del dispositivo también se especifica en la URL, pero solo hay un atributo en serie para cambiar.

Volcar la transacción .


HTTP DELETE


Obviamente elimina el objeto.

Un ejemplo

 curl -X DELETE "http://netbox.linkmeup.ru:45127/api/dcim/devices/21/" \ -H "accept: application/json" \ -H "Content-Type: application/json" \ -H "Authorization: TOKEN a9aae70d65c928a554f9a038b9d4703a1583594f"

El método DELETE es idempotente desde el punto de vista de que una consulta repetida ya no cambia nada en la lista de recursos (pero devolverá el código 404 (NO ENCONTRADO).

 curl -X DELETE "http://netbox.linkmeup.ru:45127/api/dcim/devices/21/" \ -H "accept: application/json" \ -H "Content-Type: application/json" \ -H "Authorization: TOKEN a9aae70d65c928a554f9a038b9d4703a1583594f" 

 {"detail":"Not found."}


Formas de trabajar con la API RESTful


Curl es, por supuesto, muy conveniente para los valientes guerreros de CLI, pero hay mejores herramientas.

Cartero


Postman le permite realizar consultas en la interfaz gráfica seleccionando métodos, encabezados, cuerpo y muestra el resultado en una forma legible para humanos.

Además, las consultas y los URI pueden guardarse y devolverse más tarde.

Descargar Postman en el sitio web oficial .

Entonces podemos hacer un GET:


Aquí el token se indica en el GET solo como un ejemplo.

Y entonces POST:



Postman es para usar solo con la API RESTful.
Por ejemplo, no intente enviar NETCONF XML a través de él, como lo hice al comienzo de mi carrera de automatización.
Una de las bonificaciones de la API especificada es que puede importar todos los puntos finales y sus métodos en Postman como una colección.

Para hacer esto, en la ventana Importar (Archivo-> Importar), seleccione Importar desde enlace y pegue en la ventana netbox.linkmeup.ru URL: 45127 / api / docs /? Format = openapi.



Además, todo lo que puedes encontrar se puede encontrar en las colecciones.





Python + solicitudes


Pero incluso a través de Postman, lo más probable es que no gestiones tus sistemas de producción. Seguramente, tendrá aplicaciones externas que deseen interactuar con ellas sin su participación.

Por ejemplo, un sistema de generación de configuración quiere recoger una lista de interfaces IP de NetBox.
Python tiene una maravillosa biblioteca de solicitudes que implementa el trabajo a través de HTTP.
Un ejemplo de solicitud de una lista de todos los dispositivos:

 import requests HEADERS = {'Content-Type': 'application/json', 'Accept': 'application/json'} NB_URL = "http://netbox.linkmeup.ru:45127" request_url = f"{NB_URL}/api/dcim/devices/" devices = requests.get(request_url, headers = HEADERS) print(devices.json())

Agregue un nuevo dispositivo nuevamente:

 import requests API_TOKEN = "a9aae70d65c928a554f9a038b9d4703a1583594f" HEADERS = {'Authorization': f'Token {API_TOKEN}', 'Content-Type': 'application/json', 'Accept': 'application/json'} NB_URL = "http://netbox.linkmeup.ru:45127" request_url = f"{NB_URL}/api/dcim/devices/" device_parameters = { "name": "just a simple REQUESTS girl", "device_type": 1, "device_role": 1, "site": 3, } new_device = requests.post(request_url, headers = HEADERS, json=device_parameters) print(new_device.json())


Python + NetBox SDK


En el caso de NetBox, también está el Python SDK - Pynetbox , que representa todos los puntos finales de NetBox como un objeto y sus atributos, haciendo todo el trabajo sucio para generar URI y analizar la respuesta, aunque no de forma gratuita, por supuesto.

Por ejemplo, hagamos lo mismo que arriba, usando pynetbox.
Lista de todos los dispositivos:

 import pynetbox NB_URL = "http://netbox.linkmeup.ru:45127" nb = pynetbox.api(NB_URL) devices = nb.dcim.devices.all() print(devices)

Añadir nuevo dispositivo:

 import pynetbox API_TOKEN = "a9aae70d65c928a554f9a038b9d4703a1583594f" NB_URL = "http://netbox.linkmeup.ru:45127" nb = pynetbox.api(NB_URL, token = API_TOKEN) device_parameters = { "name": "just a simple PYNETBOX girl", "device_type": 1, "device_role": 1, "site": 3, } new_device = nb.dcim.devices.create(**device_parameters) print(new_device)

Documentación de Pynetbox


Swagger


Lo que vale más gracias a la última década son las especificaciones API. Si sigue esta ruta , accederá a la interfaz de usuario de Swagger - Documentación de la API de Netbox.



Esta página enumera todos los puntos finales, métodos para trabajar con ellos, posibles parámetros y atributos e indica cuáles de ellos son necesarios. Además, se describen las respuestas esperadas.



En la misma página, puede realizar consultas interactivas haciendo clic en Pruébelo .
Por alguna razón, swagger toma el nombre del servidor sin puerto como URL base, por lo que la función Probar no funciona en mis ejemplos de Swagger. Pero puedes probarlo en tu propia instalación.
Cuando hace clic en Ejecutar Swagger, la IU generará una cadena de rizo que se puede usar para hacer una solicitud similar desde la línea de comandos.

En Swagger UI, incluso puedes crear un objeto:



Para hacer esto, es suficiente ser un usuario autorizado con los derechos necesarios.

Lo que vemos en esta página es la interfaz de usuario de Swagger, una documentación generada en base a la especificación API.

Con las tendencias en la arquitectura de microservicios, es cada vez más importante contar con una API estandarizada para la interacción entre componentes, cuyos puntos finales y métodos son fáciles de determinar tanto para la persona como para la aplicación sin hurgar en el código fuente o la documentación en PDF.

Por lo tanto, los desarrolladores de hoy siguen cada vez más el paradigma API First cuando piensan por primera vez en la API, y solo entonces en la implementación.
La API se especifica primero en este diseño, y luego la documentación, la aplicación del cliente, la parte del servidor se generan a partir de ella y se necesitan pruebas.

Swagger es un marco y lenguaje de especificación (que ahora ha sido renombrado OpenAPI 2.0), lo que le permite implementar esta tarea.
No voy a profundizar en eso.

Para más detalles aquí:



Críticas a REST y alternativas


Hay uno, si. No todo en ese mundo del año 2000 ya es tan color de rosa.

Al no ser un experto, no pretendo revelar sustancialmente el tema, pero daré un enlace a un artículo indiscutible sobre Habré .

Una interfaz alternativa para la interacción de los componentes del sistema hoy es gRPC. También profetizó un gran futuro en el campo de los nuevos enfoques para trabajar con equipos de red. Pero hablaremos de él en algún momento en el futuro, cuando llegue su turno.

También puede echar un vistazo a la prometedora GraphQL , pero de nuevo no necesitamos trabajar con ella por ahora, por lo que queda para estudio independiente.


Es importante
El token a9aae70d65c928a554f9a038b9d4703a1583594f se usó solo con fines de demostración y ya no funciona.

La indicación directa de tokens en el código del programa es inaceptable y lo he hecho aquí solo para simplificar los ejemplos.


Enlaces utiles



Gracias


  • Andrei Panfilov para revisión y edición
  • Alexander Fatin para revisión y edición

Source: https://habr.com/ru/post/485618/

More articles:


All Articles