2011-02-22 5 views
18

Considera un caso semplice in cui l'utente sta eliminando un post. Questa è una semplice richiesta DELETE/POST HTTP con un campo obbligatorio, post_id.Qual è il codice di risposta HTTP corretto per la richiesta senza campi obbligatori

Cosa dovrebbe fare il server se post_id non viene fornito?

Apparentemente, l'utente non dovrebbe mai incontrare questo comportamento, quindi cerchiamo di essere puristi.

mio primo ciak sarebbe 400 Bad Request, ma spec dice

The request could not be understood by the server due to malformed syntax. The client SHOULD NOT repeat the request without modifications. 

e direi campo mancante è OK dalla sintassi/http POV, è applicazione requisito semantica domain-specific.

200 OK con le spiegazioni è male, 500 si sente strano in quanto questo è un problema di richiesta.

Pensieri?

+1

possibile duplicato di [Quale codice di risposta dello stato HTTP dovrei usare se nella richiesta manca un parametro richiesto?] (http://stackoverflow.com/questions/3050518/what-http-status-response-code-should-i-use-if-the-request-is-missing-a-quisito) – Lucero

risposta

29

400 è la risposta corretta.

400 non è limitato a una sintassi non valida da un punto di vista HTTP. Manca un argomento obbligatorio è un errore nella sintassi definita dall'applicazione e quindi una "Bad Request"

EDIT

A prima vista sembra strano che non v'è alcun codice di ritorno separato per questo, ma il ritorno i codici sono studiati per differenziare in quali azioni il cliente dovrebbe prendere. Un codice di errore 400 indica che il client deve modificare i dati POST o la stringa di query nel formato definito dall'applicazione. Quindi è appropriato per questo caso.

+0

Ecco un elenco di Codici di risposta RESTful e alcune altre informazioni sulle migliori pratiche per REST: http://goo.gl/Nf9gt –

1

In uno scenario REST, la risorsa da eliminare deve essere identificata dall'URL, quindi l'ID della risorsa deve far parte di quell'URL per identificarlo correttamente. Una volta che tale ipotesi è corretta, l'URL o sta identificando una diversa risorsa, o non lo è (che darebbe un 404)

Nel caso generale di un parametro mancante, tuttavia, utilizzo spesso un 403 Errore proibito. Il ragionamento è che la richiesta è stata capita, ma non ho intenzione di fare come richiesto (perché le cose sono sbagliate). L'entità di risposta spiega cosa è sbagliato, quindi se la risposta è una pagina HTML, i messaggi di errore si trovano nella pagina. Se si tratta di una risposta JSON o XML, l'informazione di errore è lì.

Da rfc2616:

10.4.4 403 Forbidden

Il server capito la richiesta, ma si rifiuta di compierla.
L'autorizzazione non sarà d'aiuto e la richiesta NON DEVE essere ripetuta.
Se il metodo di richiesta non era HEAD e il server desidera rendere pubblico
perché la richiesta non è stata soddisfatta, DOVREBBE descrivere il motivo per il rifiuto nell'entità. Se il server non desidera che rendi disponibili queste informazioni al client, è possibile utilizzare il codice di stato 404
(non trovato).

Problemi correlati