En esta lección, le mostraré cómo leer y use la documentación de OpenAPI. Hay muchos tipos de sistemas de documentación. para API REST pero el más conocido y más utilizado se denomina Especificación OpenAPI. OpenAPI fue introducido por primera vez por Swagger, que es un conjunto de herramientas API. El estándar ahora se mantiene por un grupo llamado Iniciativa OpenAPI, que es un consorcio de expertos en el campo de la tecnología API. La iniciativa OpenAPI publica una especificación que dicta cómo la documentación de OpenAPI debe verse y funcionar. Echemos un vistazo a una implementación de referencia de OpenAPI, que está alojado por Swagger. Se llama la tienda de mascotas Swagger, y es un escenario de muestra que involucra mascotas, tiendas y usuarios. Este formato de documentación está destinado a ser muy fácil de leer, comprensivos y con capacidad para probar cada API desde dentro de la propia documentación. Los diversos métodos HTTP que se admiten están codificados por colores. Las solicitudes GET son azules, Las solicitudes POST son verdes, las solicitudes PUT son naranjas, y las solicitudes DELETE están en rojo. Aunque estos colores se pueden personalizar, estos son los estándares. Al hacer clic en cada punto final, puede ver todos de los detalles de ese punto final en particular dentro de la API. Por ejemplo, parámetros que podrían pasarse a la API: organismos de solicitud de muestra, tipos de transferencia de documentos admitidos, como JSON o XML, ejemplos de cuerpos de respuesta para cada tipo de código de respuesta y parámetros de consulta que se pueden pasar a la API. Además, en la parte inferior de un documento de especificación de OpenAPI, Puedes encontrar los modelos. Estos enumerarían los diferentes tipos de objetos. que podría estar incluido dentro de una respuesta del servidor. Al hacer clic, se pueden ver los diversos nombres de atributos y tipos de datos. Probemos uno de estos servicios. Si hacemos clic en la solicitud GET para encontrar mascotas por ID, podemos ver que acepta un parámetro, que se requiere llamado petId. Es un número entero, lo que significa que tiene que ser un número entero. Así que hagamos clic en el botón probarlo e ingrese una identificación en el campo. Hagamos clic en ejecutar. Y pasan algunas cosas. En primer lugar, se muestra la solicitud de curl. Curl es un programa de línea de comando que está construido en la mayoría de los sistemas operativos. Te permite emitir solicitudes a cualquier tipo de servicio HTTP pasando una variedad de argumentos al ejecutable curl. Entonces, en este caso, la URL de OpenAPI especificada fue /mascota/ llaves, petId, llave de cierre. Los nombres de variables que se muestran entre llaves están destinados para ser reemplazado con valores reales. Y los extremos de la API siempre comienzan con una barra inclinada, que se agregaría a la URL raíz de la API. Como podemos ver aquí, la URL raíz es https://petstore.swagger.io/v2. El v2 aquí significa la versión dos y esta es la forma en que generalmente se maneja el control de versiones de la API. La -H significa encabezados y, en este caso, estamos enviando un encabezado de aceptación simple, que le dice al servidor qué tipo del formato del documento que preferiríamos que los resultados se almacenan dentro. A continuación, vemos la respuesta que se emitió desde el servidor. El código de estado aquí es 200, lo que significa que la solicitud fue exitosa y lo que tenemos aquí es un cuerpo de respuesta en formato JSON y se completan los distintos campos con los valores que se recuperaron del servidor. Esto entonces representará el estado de este objeto en particular en este momento. Debajo del cuerpo de la respuesta hay encabezados de respuesta. Esta es metainformación sobre la solicitud que ayuda a proporcionar más información sobre la solicitud en sí. Ahora, intentemos probar esta API con una identificación de mascota no válida. La documentación de OpenAPI es capaz de validar esto y ni siquiera permitir que la solicitud se realice. Entonces, en lugar de poner un valor no numérico, pongamos un número que sea numérico pero no se encuentra en el servidor. Esta vez, nuestra respuesta no es un 200, es un 404. 404 es el código de estado HTTP que se emite cuando no se encuentra un recurso. Los otros métodos HTTP codificados por colores y los puntos finales se pueden usar para pasar información al servidor para cambiar el estado de un objeto. Generación de documentación OpenAPI es una operación bastante sencilla que se puede realizar de una variedad de herramientas y lenguajes de programación. La documentación de OpenAPI no suele crearse manualmente a mano, pero se genera automáticamente en función sobre los servicios que se prestan. Por ejemplo, este documento JSON describe la API y sería parte del código fuente de la API. Cuando se genera la API, los documentos de especificación se crean automáticamente en base sobre lo que hay en este archivo, hacer una documentación completa de cualquier API una operación simple que se mantendrá actualizado automáticamente con cambios en la propia API. Gracias por ver. Estén atentos a la próxima lección donde les mostraré cómo emitir solicitudes GET para leer el estado de objetos de las API REST.