Que REST PUT/POST/DELETE chamadas devem retornar por uma convenção?

Question

1. De acordo com a "ideologia de repouso", o que deve estar no órgão de resposta para solicitações de put/post/excluir?

2. E os códigos de retorno? É HTTP_OK o suficiente?

3. Qual é o motivo de tais convenções, se houver?

Encontrei uma boa postagem descrevendo as diferenças de postagem/colocação: Post vs putMas ainda não responde minha pergunta.

Answer 1

Perdoe a fragilidade, mas se você estiver descansando sobre o HTTP, então RFC7231 Descreve exatamente qual comportamento é esperado de Get, Put, Post e Excluir.

Atualização (3 de julho de 14):
A especificação HTTP intencionalmente não define o que é retornado da postagem ou exclusão. A especificação define apenas o que precisa ser definido. O restante é deixado para o implementador escolher.

Answer 2

No geral, as convenções são "pense como se você estivesse apenas entregando páginas da web".

Para uma colocação, eu retornaria a mesma visão que você obteria se tivesse uma que fosse imediatamente depois; Isso resultaria em 200 (bem, assumindo que a renderização é bem -sucedida, é claro). Para uma postagem, eu iria redirecionar para o recurso criado (supondo que você esteja fazendo uma operação de criação; se não, basta retornar os resultados); O código para uma criação bem -sucedida é um 201, que é realmente o único código HTTP para um redirecionamento que não está no intervalo 300.

Nunca fiquei feliz com o que uma delete deve retornar (meu código atualmente produz um HTTP 204 e um corpo vazio neste caso).

Answer 3

Criar um recurso geralmente é mapeado para postar, e isso deve retornar a localização do novo recurso; Por exemplo, em um andaime Rails A Create será redirecionado para o show para o recurso recém -criado. A mesma abordagem pode fazer sentido para atualizar (put), mas isso é menos uma convenção; Uma atualização precisa apenas indicar sucesso. Uma exclusão provavelmente também precisa apenas indicar sucesso; Se você deseja redirecionar, o retorno da lista de recursos provavelmente faz mais sentido.

O sucesso pode ser indicado por http_ok, sim.

A única regra rígida no que eu disse acima é que uma criação deve retornar o local do novo recurso. Isso parece um acéfalo para mim; Faz todo o sentido que o cliente precisará acessar o novo item.

Answer 4

Pelo RFC7231 não importa e pode estar vazio

Como implementamos a solução baseada em padrão da JSON API no projeto:

POST/PUT: Saídas Atributos do objeto como em get (filtro de campo/relações se aplica o mesmo)

Excluir: os dados contêm apenas nulo (por sua representação do objeto ausente)

Status para Delete Standard: 200