Páginas filhas
  • Guia de implementacao das APIs TOTVS

Versões comparadas

Chave

  • Esta linha foi adicionada.
  • Esta linha foi removida.
  • A formatação mudou.

...

  • 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 (além da versão da API), 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.
  • Ao utilizar Query Param com nome composto, é necessário sugerimos a utilização de camelCase.do padrão camelCase ou tudo minúsculo separado por hífen.
  • Sugerimos utilizar o padrão camelCase ou tudo minúsculo separado por hífen para Utilizar camelCase também para nome de recursos que contenham mais de uma palavra. Exemplos: orderItem, customerVendor,  customer-vendor etc.


Exemplo de URLs amigáveis

...

JSON deveser o formato padrão para mensagens 

Informações
titleImportante

Uma exceção seria o caso de desenvolver uma API referente à mensagem padronizada, devendo ser utilizado o padrão UpperCamelCase para as propriedades dessa mensagem.

Esse padrão respeita o protocolo pré-definido da mensagem padronizada.

Ao desenvolver uma API referente à mensagem padronizada, deve ser utilizado o padrão UpperCamelCase para as propriedades dessa mensagem. Todos os endpoints devem suportar este tipo de conteúdo.


Tipos de dados JSON

Os tipos de dados e a notação para os campos da mensagem JSON deve seguir os padrões descritos no documento ECMA-404.

...