Histórico da Página
...
Exemplo de URLs amigáveis:
Descrever plural para entidades
Colocar exemplo de filtro e expansiveis
Evitar url com mais de 3 PATH param para não dificultar leitura
https://fluig.totvs.com/api/users/{id}
https://fluig.totvs.com/api/workflowworkflows/{id}?action=execute
https://fluig.totvs.com/api/workflows/{id}/send
https://fluig.totvs.com/api/users/{alias}/communities
https://fluig.totvs.com/api/communities/{id}/users
https://fluig.totvs.com/api/users/{alias}?expand=prop1.subprop,prop2
Exemplo de URLS NÃOamigaveis e que deve ser evitadas:
...
https://fluig.totvs.com/api/document/permissions?documentId={id}
No caso em que não existe um verbo adequado pode ser usado a "ação" na url. Desenha pra pessoas.
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étodo | Descrição | Idempotente |
|---|---|---|
| GET | Retorna o valor corrente do objeto. | Sim |
| PUT | Sobrescreve o objeto ou cria um novo objeto quando aplicável. | Sim |
| DELETE | Exclui o objeto. | Sim |
| POST | Cria um novo objeto ou submete um comando ao objeto. | Não |
| HEAD | Retorna os metadados de um objeto em da requisição em casos em que o cliente não precisa do corpo das requisições do tipo GET. Endpoints que suportam o método GET PODEM suportar o método HEADER. | Sim |
| PATCH | Aplica uma atualização parcial no objeto. | Não |
| OPTIONS | Retorna informações sobre uma requisiçãosobre um endpoint e sobre as operações suportadas por ele; ver abaixo para mais detalhes. | Sim |
Post
Descrever as situações de 200 201 202
Operações do tipo POST assíncronas DEVEM retornar a localização de qualquer objeto criado que tenha um identificador.
...
| Bloco de código | ||
|---|---|---|
| ||
201202 CreatedAccepted Location: https://fluig.totvs.com/api/users/10 |
...
| 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 quando aplicávelpor padrão exceto em casos em que isso implique na performance. |
| Accept-Language | "en", "es", "pt" | Especifica o idio 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 informado na requisiçãosendo 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.
...
Visão Geral
Import HTML Content
Conteúdo das Ferramentas
Tarefas