De acordo com a "ideologia REST", o que deve estar no corpo da resposta para solicitações PUT / POST / DELETE?
E os códigos de retorno? É o HTTP_OKsuficiente?
Qual o motivo de tais convenções, se houver?
Eu encontrei um bom post descrevendo as diferenças POST / PUT: POST vs PUT Mas ainda não responde à minha pergunta.
Respostas:
Perdoe a tolice, mas se você estiver executando o REST sobre HTTP, o RFC7231 descreve exatamente o comportamento esperado de GET, PUT, POST e DELETE.
Atualização (3 de julho de 14):
A especificação HTTP intencionalmente não define o que é retornado do POST ou DELETE. A especificação define apenas o que precisa ser definido. O restante é deixado para o implementador escolher.
No geral, as convenções são "pense como se você estivesse apenas entregando páginas da web".
Para um PUT, eu retornaria a mesma visão que você obteria se fizesse um GET imediatamente depois; isso resultaria em 200 (bem, supondo que a renderização tenha êxito, é claro). Para um POST, eu faria um redirecionamento para o recurso criado (supondo que você esteja fazendo uma operação de criação; caso contrário, basta retornar os resultados); o código para uma criação bem-sucedida é 201, que é realmente o único código HTTP para um redirecionamento que não está no intervalo 300.
Eu nunca fiquei feliz com o que um DELETE deve retornar (meu código atualmente produz um HTTP 204 e um corpo vazio nesse caso).
PUTRetornar o pedido, a próxima página parece uma prática ruim, pois a atualização na página resultante fará com que o pedido seja executado novamente. Em vez disso, para mim, faz sentido redirecionar, supondo que você esteja lidando com solicitações síncronas.
PUTsolicitação, fazendo com que os dados sejam revertidos. Por exemplo, se duas pessoas estão fazendo referência à mesma página, uma faz uma atualização e a outra faz uma atualização, se a primeira pessoa atualizar para ver o resultado, isso realmente fará com que as coisas sejam revertidas antes que a segunda pessoa faça suas mudanças.
A criação de um recurso geralmente é mapeada para o POST e isso deve retornar o local do novo recurso; por exemplo, em um andaime do Rails, um CREATE será redirecionado para o SHOW do novo recurso criado. A mesma abordagem pode fazer sentido para a atualização (PUT), mas isso é menos uma convenção; uma atualização precisa apenas indicar sucesso. Uma exclusão provavelmente também precisa indicar sucesso também; se você deseja redirecionar, retornar a 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 um CREATE deve retornar o local do novo recurso. Isso parece um acéfalo para mim; faz todo o sentido que o cliente precise acessar o novo item.
Pelo RFC7231, isso não importa e pode estar vazio
Como implementamos a solução baseada em padrão json api no projeto:
post / put: gera atributos de objeto como em get (filtro / relações de campo se aplica da mesma forma)
delete: os dados contêm apenas nulo (por representar o objeto ausente)
status para exclusão padrão: 200
Eu gosto de Alfonso Tienda responder do código de status HTTP para atualizar e excluir?
Aqui estão algumas dicas:
EXCLUIR
200 (se desejar enviar alguns dados adicionais na resposta) ou 204 (recomendado).
202 A operação excluída ainda não foi confirmada.
Se não houver nada para excluir, use 204 ou 404 (a operação DELETE é idempotente, excluir um item já excluído é uma operação bem-sucedida , portanto, você pode retornar 204 , mas é verdade que idempotent não implica necessariamente a mesma resposta)
Outros erros:
- 400 Solicitação incorreta (sintaxe mal formada ou uma consulta incorreta é estranha, mas possível).
- 401 Falha na autenticação não autorizada
- 403 Proibido : falha na autorização ou ID do aplicativo inválido.
- 405 Não permitido . Certo.
- 409 Conflito de recursos pode ser possível em sistemas complexos.
- E 501 , 502 em caso de erros.
COLOCAR
Se você estiver atualizando um elemento de uma coleção
- 200/204 pelos mesmos motivos que DELETE acima.
- 202 se a operação ainda não foi confirmada.
O elemento referenciado não existe:
PUT pode ser 201 (se você criou o elemento porque esse é o seu comportamento)
404 Se você não deseja criar elementos via PUT.
400 Solicitação incorreta (sintaxe mal formada ou uma consulta incorreta mais comum do que no caso de DELETE).
401 Não autorizado
403 Proibido : falha na autenticação ou ID do aplicativo inválido.
405 Não permitido . Certo.
409 Conflito de recursos pode ser possível em sistemas complexos, como em DELETE.
422 Entidade não processável Ajuda a distinguir entre uma "Solicitação incorreta" (por exemplo, XML / JSON malformado) e valores de campo inválidos
E 501 , 502 em caso de erros.