...

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

Estrutura de URLs

Como regra geral seguimos os passos abaixo sempre que precisarmos criar um novo recurso:

...

Consideramos uma API o agrupamento de endpoints que façam parte da mesma unidade de negócio, criar um novo grupo de endpoints implica em preocupações como versionamento, disponibilidade e documentação. Usamos como base a estrutura "{protocolo}://{host}/{api}/{produto}/{agrupador}/{dominio}/{versao}/{recurso}". Ex: https://fluig.totvs.com/api/fluig/ecm/v1/users. A partir deste ponto deve-se considerar como regra básica a complexidade necessária para descobrir estes endpoints, ou seja, o agrupamento deve facilitar e não complicar a descoberta dos serviços.

...

Estrutura OAS (Open Api Specification 3.0.1):

openapi: 3.0.1
info:
  title: Estrutura de Url para API's
  description: 'Consideramos uma API o agrupamento de endpoints que façam parte da mesma unidade de negócio. Usamos como base a estrutura "{protocolo}://{host}/{api}/{produto}/{agrupador}/{dominio}/{versao}/{recurso}"'
  version: '1.0'
externalDocs:
  url: 'http://tdn.totvs.com/display/INT/Guia+de+implementacao+das+APIs+TOTVS'
servers:
  - url: '{protocolo}://{host}/{api}/{produto}/{agrupador}/{dominio}/{versao}/{recurso}'
    variables:
      protocolo:
        default: https
        enum:
          - http
          - https
      host:
        default: host
      api:
        default: api
      produto:
        default: produto
      agrupador:
        default: agrupador
      versao:
        default: versao
      recurso:
        default: recurso
paths: {}
components: {}

...

Exemplo de filtros no padrão odata:

Filtros de data Modificação (opcional)

...

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 o fizerem devem respeitar a utilização conforme descrita.

PUT http://totvs.com/api/users/10

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

PATCH http://totvs.com/api/fluig/fdn/v1/users/10

[
  { "op": "replace", "path": "/name", "value": "Bob" }
]

Corpo de mensagem e Query String

...

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://totvs.com/api/fluig/fdn/v1/users
{
 ...
}

202 Accepted
Location: https://totvs.com/api/fluig/fdn/v1/queue/10

Como escolher o método adequado

...

A utilização destes cabeçalhos não é obrigatória para todos os endpoints, mas os que os utilizarem devem obedecer as regras descritas abaixo.

Padrões de cabeçalhos de respostas

Endpoints devem retornar estes cabeçalhos em todas as repostas, a menos que explicitamente citado o contrário na coluna obrigatório.

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 devem 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érie de cabeçalhos para quase todas as situações e estas sempre tem precedência a um cabeçalho customizado.

...

...