Swagger é uma ferramenta especial que compõe automaticamente o RESTful API documento da sua candidatura.
A sua vantagem reside no facto de lhe permitir não só ver todos os pontos finais do pedido, mas também testá-los imediatamente em acção, enviando um pedido e recebendo uma resposta.
Para aceder a Swaggeré necessário continuar a Preview na aplicação publicada e clique no nome do plano de publicação requerido (Deploy Plan).
Na janela recentemente aberta é mostrada uma lista de parâmetros e métodos disponíveis associados a estes parâmetros. Alguns pedidos estão disponíveis apenas para certos grupos de utilizadores autorizados (ver a Middleware do Auth module para cada pedido específico no Endpoints secção). A Bearer Token é necessário para pedidos que são permitidos apenas para utilizadores autorizados.
Pode aceder directamente ao ponto final correspondente em Swagger para obter este símbolo (Auth secção, POST /auth pedido).
Imprensa Try it out e introduzir login e palavra-chave para obter uma ficha.
O pedido será enviado em Execute. Se tiver sucesso, verá um token campo com o Bearer token valor.
A segunda forma de obter um token de utilizador autorizado é que o token pode ser encontrado no corpo do pedido da aplicação implantada.
- Prima F12 no seu navegador da Internet para abrir a ferramenta do programador.
- Envie qualquer pedido na sua aplicação implantada (para actualizar tabelas, por exemplo). O utilizador que está a enviar este pedido tem de ser autorizado a aceder a este ponto final.
- Abrir Network e encontrar o pedido correspondente.
- Ir para Headers tab e encontrar Request Headers secção. Bearer token será apresentada em Authorization.
Fornecer Bearer token para Swagger pressionando Authorize e colando o valor que copiou no passo anterior.
Para pedidos de teste seleccione o grupo desejado e o método que pretende executar. Prima . Try it out e preencher os parâmetros de entrada do pedido. Clicar em Execute para executar a resposta.
A resposta mais esperada, se o pedido for processado correctamente pelo servidor, tem o código 200 e mostra como deve ser a estrutura da resposta.
401 - o pedido não foi concluído com sucesso porque o token de autorização requerido está em falta ou é inválido.
404 - o pedido foi processado com sucesso, mas o recurso solicitado não foi encontrado.
422 - os parâmetros incorrectos foram passados para a introdução do pedido.
500 - um erro no processamento do pedido pelo servidor.
Levantar erro personalizado
Para BPs personalizados e pedidos relacionados, é possível criar códigos de erro personalizados com descrições usando o Raise Error bloco no editor da BP. Um exemplo de tal processo está abaixo:
Neste caso, se o pedido para o ponto final associado ao BP acima falhar, o servidor emitirá um 418 erro contendo o texto de erro ao executar o DB: Create Candidate block. O código de erro neste exemplo pode ser qualquer um que o utilizador especifique.
Nota: o código de resposta de erro do cliente do bule HTTP 418 I'm a teapot indica que o servidor se recusa a fazer café porque é, permanentemente, um bule de chá. Um bule combinado de café/chá que está temporariamente fora do café deve, em vez disso, devolver 503. Este erro é uma referência a Hyper Text Coffee Pot Control Protocol definida nas piadas dos tolos de Abril em 1998 e 2014.
