Histórico da Página
...
- 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 | ||
---|---|---|
| ||
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.
...
Visão Geral
Import HTML Content
Conteúdo das Ferramentas
Tarefas