Integrações

Páginas filhas
  • Guia de implementacao das APIs TOTVS

Versões comparadas

Versão antiga 127

changes.mady.by.user Elvis Leonardo de Oliveira Brito

Gravado em

comparado com

Nova versão 128

changes.mady.by.user Elvis Leonardo de Oliveira Brito

Gravado em

Chave

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

...

Os termos deve, não deve, requerido, pode, não pode, recomendado, opcional devem ser interpretados como descritos no padrão RFC-2119.

Corpo de mensagem e Query String

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

...

MétodoDescriçãoIdempotente
GETRetorna o valor corrente do objeto.Sim
PUT

Sobrescreve o objeto quando aplicável. Por exemplo: O cliente gostaria de sobrescrever o usuário com novos valores:

Bloco de código
languagetext
PUT http://totvs.com/api/users/10

{
  name: "",
  age: 20,
  ...
}
Informações
titleImportante

Caso o cliente não informe alguma propriedade para ser atualizada, está deve ser considerada nula. Está informação deve estar clara na documentação do método para que o cliente não há utilize inadvertidamente, ou pode-se optar por não implementá-la.

Sim
DELETE

Exclui o objeto.

Sim
POSTCria um novo objeto ou submete um comando ao objeto.Não
HEADRetorna os metadados da requisição em casos em que o cliente não precisa do corpo das requisições do tipo GET.Sim
PATCH

Também usado para atualizar uma entidade, mas diferente do PUT, recebe em seu corpo uma série de instruções ou o estado no qual o cliente gostaria que a entidade estivesse no final da operação. Deve ser tratado de forma atômica, ou seja, ou todas as instruções foram completadas com sucesso ou deve retornar erro ao cliente.

PATH pode causar efeitos colaterais e portanto não é considerado seguro ou idempotente.

Bloco de código
languagetext
PATCH http://totvs.com/api/fluig/fdn/v1/users/10

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

O servidor deverá implementar o serviço de modo que apenas o nome do usuário seja atualizado e todas as outras propriedades sejam mantidas.

Não
OPTIONSDeve retornar pelo menos o campo Allow no cabeçalho da resposta listando os verbos suportados pelo endpoint.Sim

Corpo de mensagem e Query String

Métodos DELETE, GET, HEAD e OPTIONS não deve ser utilizado corpo na mensagem e sim utilizar query string .


Campo chave (id) dos verbos GET, PUT e DELETE


O valor passado como parâmetro de URL (path param) dos verbos GET, PUT e DELETE deve representar o identificador único do registro dentro do contexto do endpoint. Ou seja, baseado no valor (id) passado, o provedor de informação deve ser capaz de identificar de forma inequívoca o registro dentro da base de dados. Caso necessário, é possível concatenar diversos campos para compor o identificador.

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:

...