Histórico da Página
...
| Header | Tipo | Descrição |
|---|---|---|
| Authorization | literal | Cabeçalho usado para autorização das requisições |
| Date | data | Data e hora da requisição com base no calendário do cliente no formato estipulado em RFC 5322 |
| Accept | enumerador de tipo de conteúdo | O tipo de conteúdo esperado para a resposta como por exemplo:
De acordo com os padrões HTTP, este valor é apenas uma dica para o servidor e as respostas PODEM retornar valores em formatos diferentes dos informados. |
| Accept-Encoding | Gzip, deflate | Endpoints DEVEM suportar codificação GZIP e DEFLATE por padrão exceto em casos em que isso implique na performance. |
| Accept-Language | "en", "es", "pt" | Especifica o idioma preferencial da resposta. Endpoints DEVEM suportar e respeitar estes valores em casos em que uma mensagem é retornada ao usuário. Caso o idioma informado não seja suportado deve retornar no idioma padrão (pt). |
| Content-Type | tipo de conteúdo | Tipo do conteúdo sendo passado na requisição. O endpoint DEVE respeitar esta informação na hora de interpretar a informação passada pelo cliente ou retornar um erro apropriado caso o valor não for suportado. |
Mensagens
Durante a construção das mensagens que serão transmitidas entre o cliente e endpoint deve-se garantir a consistência entre nomes de propriedades e objetos quando os mesmo fizerem parte de um mesmo grupo ou assunto.
Mensagens de retorno do endpoint para o cliente devem obedecer a estrutura definida para mensagens de erro ou mensagens de sucesso
...
Padrões de cabeçalhos de responta
Endpoints DEVEM retornar estes cabeçalhos em todas as reposta a menos que explicitamente citado o contrário na coluna obrigatório
| Cabeçalho | Obrigatório | Descrição |
|---|---|---|
| Date | Em todas as respostas | Hora em que a resposta foi processada baseada no calendário do servidor no formato estipulado em RFC 5322. Ex: Wed, 24 Aug 2016 18:41:30 GMT. |
| Content-Type | Em todas as respostas | O tipo de conteúdo enviado do endpoint para o servidor. |
| Content-Encoding | Em todas as respostas | GZIP ou DEFLATE como for apropriado. |
Cabeçalhos customizados
Cabeçalhos customizados NÃO DEVEM ser utilizados para representar qualquer estado, valor ou ação sobre a entidade representada pela url. Isso quer dizer que cabeçalhos NÃO DEVE ter relação com o cliente do endpoint (mobile, desktop, etc), url, corpo da mensagem, corpo da resposta ou parâmetros da url. O protocolo HTTP oferece uma séria de cabeçalhos para quase todas as situações e estas sempre tem precedência a um cabeçalho customizado.
Nos casos extremos onde não houver outra maneira de representar a informação, pode-se optar por criar um cabeçalho que DEVE estar descrito na documentação do endpoint e este DEVE seguir o padrão X-fluig-[Nome do cabeçalho]
Formato das mensagens de resposta
Precisamos decidir se vamos suportar XML E Json ou apenas um deles.
JSON DEVE ser o formato padrão para mensagens e as propriedades destas mensagens DEVEM ser escritas usando camelCase.
Todos os endpoints DEVEM suportar este tipo de conteúdo.
Mensagens de erro
Para todas as mensagens que representam um
...
Mensagem de erro
Todos as respostas de erro (códigos HTTP 4xx e 5xx) devem retornar uma mensagem contendo deve-se retornar obrigatoriamente os campos a seguir:
| Bloco de código | ||
|---|---|---|
| ||
{
code: "Código identificador do erro",
helpUrl: "link para a documentação do error",
message: "Literal no idioma da requisição descrevendo o erro para o cliente",
detailedMessage: "Mensagem técnica e mais detalhada do erro"
} |
O campo code deve identificar unicamente o erro na documentação da API;
Informações Todos os códigos de error DEVEM estar mapeados e listados na documentação da API.
- O campo helpUrl deve apontar para diretamente para documentação do erro na API;
- O campo message deve descrever o erro de forma não técnica e pode ser usado pelos clientes para exibição ao usuário. O texto deste campo deve respeitar o idioma usado na requisição (definido pelo cabeçalho Accept-Language ou o padrão caso este não seja especificado);
- O campo detailedMessage deve descrever o erro de forma mais técnica e pode conter referências que ajudem na correção / localização do erro no contexto do servidor do fluig.
| Informações |
|---|
Em alguns casos se faz necessário retornar mais campos do que os estipulados acima. Nestes casos a informação deve ser considerada opcional do ponto de vista do cliente, ou seja, o cliente não deve depender dela para o tratamento do erro. |
...
Código 4xx versus 5xx
Dividimos os erros em duas categorias: Erros de negócio ou requisição e Erros não esperados.
...
Visão Geral
Import HTML Content
Conteúdo das Ferramentas
Tarefas