Swagger es una herramienta especial que compone automáticamente el RESTful API documento de su aplicación.
Su ventaja radica en que permite no sólo consultar todos los endpoints de la aplicación, sino también probarlos inmediatamente en acción enviando una petición y recibiendo una respuesta.
Para acceder a Swaggerdebe pulsar el botón Preview en la aplicación publicada y hacer clic en el nombre del plan de publicación requerido (Deploy Plan).
En la nueva ventana abierta se muestra una lista de los puntos finales disponibles y los métodos asociados a estos puntos finales. Algunas solicitudes sólo están disponibles para determinados grupos de usuarios autorizados (véase el Middleware del Auth module para cada solicitud específica en la sección Endpoints sección). A Bearer Token es necesario para las solicitudes que están permitidas sólo para los usuarios autorizados.
Puede acceder al punto final correspondiente directamente en Swagger para obtener este token (Auth sección, POST /auth solicitud).
Pulse Try it out e introduzca el nombre de usuario y la contraseña para obtener el token.
La solicitud se enviará en Execute. Si se ha realizado con éxito, verá un token campo con el Bearer token valor.
La segunda forma de obtener un token de usuario autorizado es que el token se puede encontrar en el cuerpo de la solicitud de la aplicación desplegada.
- Pulse F12 en su navegador web para abrir la herramienta del desarrollador.
- Envíe cualquier solicitud en su aplicación desplegada (para actualizar tablas, por ejemplo). El usuario que envíe esta solicitud debe estar autorizado para acceder a este punto final.
- Abra Network y busque la solicitud correspondiente.
- Vaya a la pestaña Headers y busque la sección Request Headers sección. Bearer token se presentará bajo Authorization.
Proporcione Bearer token a Swagger pulsando Authorize y pegando el valor que ha copiado en el paso anterior.
Para probar las solicitudes seleccione el grupo deseado y el método que desea ejecutar. Pulse Try it out y rellene los parámetros de entrada de la solicitud. Pulse Execute para ejecutar la respuesta.
La respuesta más esperada, si la petición es procesada correctamente por el servidor, tiene el código 200 y muestra cómo debería ser la estructura de la respuesta.
401 - la petición no se ha completado con éxito porque falta el token de autorización requerido o no es válido.
404 - la solicitud se ha procesado correctamente, pero no se ha encontrado el recurso solicitado.
422 - se han pasado parámetros incorrectos a la entrada de la petición.
500 - un error en el procesamiento de la solicitud por parte del servidor.
Levantar un error personalizado
Para los BPs personalizados y las solicitudes relacionadas, es posible crear códigos de error personalizados con descripciones utilizando el bloque Raise Error en el editor de BP. A continuación se muestra un ejemplo de este proceso:
En este caso, si la petición al endpoint asociado con el BP anterior falla, el servidor emitirá un error 418 que contiene el texto de error al ejecutar el DB: Create Candidate block. El código de error en este ejemplo puede ser cualquiera que el usuario especifique.
Nota: el código de respuesta de error del cliente HTTP 418 I'm a teapot indica que el servidor se niega a preparar café porque es, permanentemente, una tetera. Una cafetera/tetera combinada que se queda temporalmente sin café debería devolver, en cambio, 503. Este error es una referencia a Hyper Text Coffee Pot Control Protocol definida en las bromas de April Fools de 1998 y 2014.
