Índice

Introdução

Este documento define os padrões que devem ser adotados durante a implementação de novas APIs publicas ou privadas na plataforma do fluig incluido:

• Definir práticas e padrões consistentes para todos os endpoints das APIs do fluig;
• Garantir a utilização mais próxima possível das boas práticas estipuladas pelos padrões REST/HTTP;
• Tornar os serviços da plataforma fluig acessíveis através de APIs mais fáceis e documentadas para desenvolvedores e consumidores;
   

Comitê

Criamos um comitê interno, formado com um integrante de cada squad, para discutir e garantir a execução dos padrões definidos neste documento.

Cada um dos membros deve obrigatoriamente ser incluído no pull request de novas APIs publicas e cadas um deles é responsável por garantir a correta disseminação e implementação dentro de seu próprio time das APIs privadas.

Nomenclaturas

Cliente: Qualquer aplicativo que faça uma requisição para um endpoint do fluig.

Mensagem: Conteúdo enviado no corpo de uma requisição ou resposta do servidor.

Endpoint: Representa um método ou entidade que pode ser acessado através de uma requisição ao servidor do fluig.

Verbo: Tipo de requisição usada para acessar um endpoint (GET, POST, PUT, HEAD, etc).

API: Grupo de endpoints

APIs Privadas são todas as APIs acessíveis apenas pelos times do fluig

APIs Publicas são todas as APIs que podem ser acessadas por clientes externos aos times de desenvolvimento do fluig.

Estrutura de URLs

Os caminhos definidos para cada endpoint devem ser de fácil leitura e significativos para o cliente para facilitar a sua descoberta e adoção. Os pontos abaixo DEVEM ser considerados ao criar uma URL:

• Ao referenciar uma entidade na URL ela DEVE estar no plural. Ex. /users ao invés de /user
• Evite caminhos com mais de 3 parâmetros pois isso dificulta a leitura e normalmente indica um problema arquitetural.
• O caminho DEVE apontar para um recurso e não para uma ação sobre a entidade, use os verbos HTTP para representar uma ação. Nos casos onde não exista um verbo apropriado a ação pode ser informada como parâmetro no caminho da url ou na url.

Exemplo de URLs amigáveis:

Colocar exemplo de filtro e expansíveis

• Entidade apresentada no plural e uso correto do parâmetro na url.
  • https://fluig.totvs.com/api/users/{id}
• Ações sobre entidades no caminho da url e como parâmetro da url.
  • https://fluig.totvs.com/api/workflows/{id}?action=execute
  • https://fluig.totvs.com/api/workflows/{id}/send
• Relacionando entidades diretamente no caminho
  
  • https://fluig.totvs.com/api/users/{alias}/communities
  • https://fluig.totvs.com/api/communities/{id}/users
• URL com suporte a campos expansíveis (linkar para a sessão de campos expansíveis)
• https://fluig.totvs.com/api/users/{alias}?expand=prop1.subprop,prop2
  
  

Exemplo de URLS NÃO amigaveis e que deve ser evitadas:

• Redundância na definição da url
  • https://fluig.totvs.com/api/communty/listCommunities
• Ordenação especificada na url
  • https://fluig.totvs.com/api/communty/listCommunitiesWithRelevance
• Verbos definidos na url ao invés de usar o verbo HTTP e falta de pluralização no substantivo.
  
  • https://fluig.totvs.com/api/correlationquestion/create
  • https://fluig.totvs.com/api/user/create
  • https://fluig.totvs.com/api/user/delete
• Identificador da entidade definido como parâmetro e não como caminho (na url)
  • https://fluig.totvs.com/api/document/permissions?documentId={id}

Apesar de o padrão definido no documento RFC 7230 da especificação do HTTP 1.1 não definir um tamanho maximo para a url nenhum endpoint do fluig deve ser identificado com uma url maior que 2000 caracteres para garantir que todos os navegares modernos sejam suportados

Métodos suportados

Endpoints devem usar os métodos HTTP adequados e devem respeitar a idempotência da operação.

Na tabela abaixo serão listados os métodos que DEVEM ser suportados. Nem todos os endpoints devem suportar todos os métodos, mas os que usarem DEVEM respeitar a utilização conforme descrita.

POST http://fluig.totvs.com/api/users/10

{
  name: "",
  age: 20,
  ...
}

POST http://fluig.totvs.com/api/users/10

{
  name: "Novo nome do usuário"
}

POST x PUT x PATCH

Deve-se atentar aos códigos de retorno para os tipos de operações definidos para usar estes métodos principalmente nos casos definidos abaixo:

POST https://fluig.totvs.com/api/users
{
 ...
}

202 Accepted
Location: https://fluig.totvs.com/api/users/10

Padrões de cabeçalhos de requisição

A utilização destes cabeçalhos não é obrigatória para todos os endpoints mas os que os usarem DEVEM obedecer as regras descritas aqui.

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

Mensagem de erro

Todos as respostas de erro (códigos HTTP 4xx e 5xx) devem retornar uma mensagem contendo obrigatoriamente os campos a seguir:

{
    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;
• 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.
  
  

Código 4xx versus 5xx

Dividimos os erros em duas categorias: Erros de negócio ou requisição e Erros não esperados.

Erros de negócio ou requisição são aqueles causados por dados inválidos na requisiçõe ou intencionalmente lançados do endpoint para o cliente. Todos os erros deste tipo devem obrigatoriamente retornar um código HTTP 4xx. Ex:

1. O cliente chamou um endpoint mas não estava devidamente autenticado. Deve ser retornado o código 401 - Unauthorized
2. O cliente chamou um endpoint mas mesmo estando autenticado não possui as permissões necessárias para efetuar a operação. Deve retornar o código 403 - Forbidden
3. O cliente chamou o endpoint para buscar um usuário (Ex: /users/{id}) mas o usuário não existe. Deve ser retornado o código de erro 404 - Not found
4. O cliente chamou o endpoint para efetuar alguma operação mas por alguma regra de negócio a operação não pode ser concluída e não existe um código de erro HTTP apropriado para descrevê-lo. Deve ser retornado o código de error 400 - Bad Request
5. O cliente chamou o endpoint passando no cabeçalho que aceita como retorno xml (Content-Type: text/xml) mas o serviço consegue retornar JSON. Deve retornar o erro HTTP 406 - Not Acceptable
6. O cliente chamou um endpoint para subir um documento mas o usuário logado passou o limite de espaço estipulado para seu perfil. Deve retornar o código 507 - Insufficiente Storage;

Erros não esperados são os erros não tratados ou não intencionais. Esse tipo de erro deve sempre retornar códigos HTTP 5xx. Ex:

1. O cliente chamou um endpoint mas o servidor não pode responder por que estava sobrecarregado. Deve retornar o código 503 - Service Unavailable;
2. O cliente chamou um endpoint para subir um documento mas não havia espaço em disco no servidor. Deve retornar o código 507 - Insufficiente Storage;