# Cliente REST El bloque Cliente REST está diseñado para realizar solicitudes HTTP. Soporta los métodos principales de solicitudes HTTP, lo que permite al Usuario interactuar con APIs (incluyendo APIs RESTful), utilizando: * GET: Recuperación de datos. * POST: Envío de datos para crear un nuevo recurso. * PUT: Actualización de un recurso existente. * DELETE: Eliminación de un recurso. * OPTIONS: Obtención de información sobre los métodos soportados para el recurso especificado.
Se debe tener en cuenta que el bloque Ejecutar solicitud HTTP en Sherpa Designer está obsoleto (se recomienda utilizar el bloque Cliente REST, ya que es más funcional). Sin embargo, dado que muchos Usuarios aún utilizan el bloque Ejecutar solicitud HTTP, los desarrolladores lo han dejado disponible para garantizar la compatibilidad hacia atrás.
Los Usuarios pueden configurar de manera flexible los encabezados de las solicitudes, agregar cookies y también pasar parámetros en la URL. Estas capacidades pueden ser útiles para: * Especificar el formato de los datos, como \`Content-Type\` o \`Accept\`. * Configurar la autorización, utilizando encabezados del tipo \`Authorization\`, lo que permite trabajar con OAuth, claves API o autenticación básica. * Pasar parámetros adicionales en las solicitudes, lo que puede ser útil para filtrar o clasificar datos. Al utilizar los métodos POST y PUT, el Cliente REST permite al Usuario enviar datos en el cuerpo de la solicitud. Puede: * Enviar datos en formato JSON, XML u otros tipos. * Cargar archivos, permitiendo la integración con servicios que requieren la transferencia de contenido (por ejemplo, imágenes o documentos). Esto es especialmente útil para trabajar con APIs que aceptan estructuras de datos complejas. Además, el bloque Cliente REST proporciona capacidades para: * Configurar el tiempo de espera (timeout): El Usuario puede definir cuánto tiempo su solicitud esperará una respuesta del servidor antes de ser cancelada. * Manejo de errores: por defecto, el bloque devuelve un error si el servidor responde con un estado diferente a exitoso (2xx), pero el Usuario puede configurarlo para que continúe realizando acciones dependiendo de los códigos de error. Para garantizar la seguridad o eludir restricciones de red, el bloque Cliente REST soporta el uso de servidores proxy. El Usuario puede configurar: * Dirección del proxy, * Puerto, * Autorización necesaria para acceder al proxy. Esto es útil en casos donde es necesario interactuar con una API que solo está disponible a través de conexiones intermedias especificadas. ### Ejemplo de uso: Yandex Speech API Supongamos que el Usuario desea convertir un archivo de audio en formato .wav a texto, utilizando Yandex Speech API. Con el bloque Cliente REST, esto se puede hacer de la siguiente manera: 1\. Configuración de la solicitud: URL: \` Método: \`POST\` Encabezados: Autorización: Api-Key \ Content-Type: application/octet-stream 2\. Envío de datos: En el cuerpo de la solicitud, el Usuario cargará el archivo de audio .wav. 3\. Manejo de la respuesta: El Usuario recibirá el resultado en texto, que puede ser utilizado en la aplicación. ### Ejemplo de uso del Cliente REST con un arreglo de campos de tipo \`multipart/form-data\` Al trabajar con APIs que requieren el envío de datos en formato \`multipart/form-data\`, es importante configurar correctamente el cliente. Este formato se utiliza a menudo para cargar archivos, así como para enviar datos de formularios. Supongamos que el Usuario tiene una API que le permite cargar archivos y enviar datos de texto adicionales. Para esto, es necesario utilizar el formato \`multipart/form-data\`. Por ejemplo, supongamos que el Usuario desea enviar una imagen y una descripción de la misma al servidor. Ejemplo de llenado de campos del bloque Cliente REST: | Campo | Ejemplo de llenado | Comentario | | ------------------------- | ------------------------------------------------- | -------------------------------------------------------------------------------------------------------------------------------------------------------------------------- | | URL | | Enlace a la API que acepta archivos cargados. | | Tipo de solicitud | POST | Estamos enviando datos al servidor, por lo que utilizamos el método POST. | | Codificación | UTF-8 | Codificación estándar para páginas web. | | Encabezado Accept | application/json | Especifique qué tipo de respuesta espera del servidor. | | Parámetros | {"description"="Descripción del archivo cargado"} | Especifique datos adicionales que desea enviar junto con el archivo. | | Encabezados | {"Authorization"="Bearer YourAccessToken"} | Especifique el encabezado de autorización. | | Cookies |


| Lista de cookies, si es necesario para la solicitud. Si el servidor requiere autorización a través de cookies, agréguelo aquí, obteniéndolas del bloque "Obtener Cookies". | | Archivos | @{"file"="C:\path\to\your\file.jpg"} | Especifique el archivo que desea cargar. Utilice la ruta completa al archivo. | | Contenido de la solicitud |


| No llene este campo al usar \`multipart/form-data\`, ya que los datos se generan automáticamente. | | Encabezado Content-Type | multipart/form-data | Especifique el tipo de contenido que corresponde a los datos enviados. | | Tiempo de espera | 30 | Establezca el tiempo de espera en segundos para la respuesta del servidor. | | Resultado |


| El campo se llenará automáticamente al ejecutar la solicitud. | | Código de respuesta |


| El campo se llenará automáticamente al ejecutar la solicitud. | | Encabezados de respuesta |


| El campo se llenará automáticamente al ejecutar la solicitud. | | Cookies |


| El campo se llenará automáticamente al ejecutar la solicitud. | | Nivel de mensajes | Predeterminado | Seleccione el nivel de mensajes que se mostrará al ejecutar el bloque. | | Texto de error |


| El campo se llenará automáticamente en caso de que ocurran errores. | ### Categorías de errores Los errores que pueden ocurrir al trabajar con la API se pueden dividir en varias categorías: * Error de red: Problemas de red, como falta de conexión, tiempos de espera y otros fallos a nivel de protocolo de transporte. * Errores del cliente (4xx): Estos son errores relacionados con las solicitudes enviadas al servidor. Indican que algo está mal con la solicitud o los parámetros. Ejemplos: \`400 Bad Request\`: Solicitud incorrecta, error de sintaxis. \`401 Unauthorized\`: Acceso denegado, se requiere autorización. \`404 Not Found\`: Recurso solicitado no encontrado. * Errores del servidor (5xx): Estos errores indican problemas del lado del servidor. Ejemplos: \`500 Internal Server Error\`: Error interno del servidor, error general sin especificación. \`503 Service Unavailable\`: Servicio temporalmente no disponible, puede estar sobrecargado o en mantenimiento. ### Manejo de errores en el Cliente REST Para un manejo efectivo de errores en el Cliente REST, se prevén varios métodos: * Estrategia de manejo: Configuración de la lógica de manejo de errores según el estado de la respuesta del servidor. Por ejemplo: Para códigos 4xx, puede mostrar una notificación al usuario sobre la solicitud incorrecta. Para códigos 5xx, se puede implementar una lógica de reintento con algunos retrasos. * Personalización de mensajes de error: Puede configurar y mostrar mensajes más comprensibles para los usuarios, proporcionando detalles sobre el error. Esto es importante para mejorar la usabilidad. El registro de errores es una parte importante de la depuración y diagnóstico. Puede configurar el almacenamiento de errores para: * Registrar respuestas erróneas en un archivo o base de datos para análisis posterior. * Incluir información adicional sobre el contexto del error (por ejemplo, URL de la solicitud, encabezados, cuerpo de la solicitud) para facilitar el diagnóstico. En casos donde la solicitud no puede ser completada debido a errores temporales de red o servidor: * Establezca tiempos de espera para las solicitudes, para que no se queden colgadas indefinidamente. * Implemente un mecanismo de reintentos con retraso exponencial para errores temporales. Por ejemplo, si el servidor está temporalmente no disponible (código 503), tiene sentido intentar repetir la solicitud después de unos segundos. Además del manejo de errores en el código, es útil estudiar la estructura de los códigos de error estándar para entender cómo se agrupan y qué significan. El uso de códigos estándar le ayudará a identificar más rápidamente la causa del problema y solucionarlo. --- # Agent Instructions: Querying This Documentation If you need additional information that is not directly available in this page, you can query the documentation dynamically by asking a question. Perform an HTTP GET request on the current page URL with the `ask` query parameter: ``` GET https://docs.sherparpa.ru/es/sherpa-rpa/sherpa-designer/rest-klient.md?ask= ``` The question should be specific, self-contained, and written in natural language. The response will contain a direct answer to the question and relevant excerpts and sources from the documentation. Use this mechanism when the answer is not explicitly present in the current page, you need clarification or additional context, or you want to retrieve related documentation sections.