Compatibilidade de status HTTP

votos
2

Estou actualmente a implementar uma API RESTful (nada sério, só por um mecanismo de blog que eu estou desenvolvendo para se divertir) e eu tenho algumas perguntas sobre a compatibilidade de status HTTP.

Para criar um novo post eu tenho que fazer um pedido POST, se tudo correr bem, o cargo é criado e, em seguida, retornou no formato correspondente ao pedido.

Eu li sobre esta página da Wikipedia sobre 200 OKstatus que

Em um pedido POST a resposta conterá uma entidade que descreve ou que contém o resultado da acção

OK. Mas depois há o 201 Createdstatus:

O pedido foi cumprida e resultou em um novo recurso que está sendo criado.

Então, minha pergunta é: quando uma solicitação POST é bem sucedido e um novo post é criado wan i enviar de volta estes código de status dois http ou apenas um de cada vez é permitido?

Eu não obter esta informação a partir da RFC , pensei que não lê-lo inteiramente.

Estou pensando que apenas um status HTTP de cada vez é permitido, mas, em seguida, qual deles devo usar?

EDIT (nova pergunta): E se a ação é editar um post existente? Eu tenho um pedido PUT em um URI e desta vez eu vou ter que enviar de volta 200 OKe, em seguida, um Location:cabeçalho também? Porque este local será exatamente o mesmo que o URI do pedido PUT, exceto que ele deve ser um pedido GET, que está tudo bem?

Publicado 05/09/2009 em 20:26
fonte usuário
Em outras línguas...                            


2 respostas

votos
6

Todos os status 2xx são bem sucedida. No entanto, no caso de um POST para criar um recurso, você provavelmente deve retornar um 201 juntamente com um local para o recurso. A partir da especificação:

http://www.w3.org/Protocols/rfc2616/rfc2616-sec10.html#sec10.2.2

O pedido foi cumprida e resultou em um novo recurso que está sendo criado. O recurso recém-criado pode ser referenciado pelo URI (s) retornou na entidade da resposta, com a URI mais específico para o recurso dado por um campo de cabeçalho Location. A resposta deve incluir uma entidade que contém uma lista de características dos recursos e localização (s) a partir do qual o agente do usuário ou usuário pode escolher o mais adequado. O formato entidade é especificado pelo tipo de mídia dada no campo de cabeçalho Content-Type. O servidor de origem deve criar o recurso antes de devolver o código de 201 status. Se a ação não pode ser realizada imediatamente, o servidor deve responder com 202 (aceitado) resposta em seu lugar.

Em outras palavras, você deve retornar:

201 Created
Location: http://www.example.com/path/to/resource

O navegador irá então saber que é o recurso para se referir a, e que o pedido foi bem sucedido, ao mesmo tempo. Você não precisa se preocupar com multi-estado.

Respondeu 05/09/2009 em 20:37
fonte usuário

votos
0

[Sei que esta resposta é um pouco tarde para o consulente original, mas outros que podem tropeçar a questão no futuro talvez possa estar interessado]

Além do que AlBlue disse:

Em outras palavras, você deve retornar:

201 Created
Location: http://www.example.com/path/to/resource

Você também pode retornar a entidade recém-criada, contanto que você também definir o Content-Locationcabeçalho:

POST /make-new-resource

então

HTTP/1.1 201 Created
Location: http://www.example.com/path/to/resource
Content-Location: http://www.example.com/path/to/resource

[representation of new resource]

Se você não incluir um Content-Locationcabeçalho, qualquer corpo de resposta será interpretado como uma lista de hipertexto de representações de recursos (em vez de um único representante.) Para o recurso recém-criado.

Respondeu 16/11/2012 em 12:26
fonte usuário

Cookies help us deliver our services. By using our services, you agree to our use of cookies. Learn more