2012-12-12 15 views
5

Attualmente sto sviluppando un'API Web e ho uno scenario specifico che non riesco a determinare quale codice di stato HTTP sarebbe più appropriato restituire.Impossibile eliminare l'ultimo contatto: quale codice di stato Http?

Lo scenario

Ho una risorsa "cliente" che possiede un insieme di risorse di contatto.

L'invariante è che un client deve sempre avere almeno un contatto. Pertanto, se viene effettuata una richiesta per eliminare un contatto e questo contatto è l'ultimo contatto rimanente per il client specificato, è necessario restituire una risposta HTTP appropriata che indica che la richiesta non può essere soddisfatta mentre "Impossibile eliminare l'ultimo contatto".

La mia sensazione è questo dovrebbe rientrare nella categoria di

Ho considerato i seguenti codici di stato "4xx di errore del client":

400 Richiesta - ho governato questo fuori come è in particolare per quanto riguarda le richieste malformate in cui il server non è in grado di capire.

405 Metodo non consentito - all'inizio sembra adatto, ma penso che 405 indichi che questo metodo non dovrebbe mai essere consentito, tuttavia lo scenario sopra riportato è solo transitorio. Pensieri?

409 Conflitto - Sono stato inclinato verso questo, tuttavia l'esempio comune fornito per questo codice è generalmente un'eccezione di concorrenza/modifica conflitto.

Qualcuno ha una guida su come dovrei rispondere in questo scenario?

+0

'409' è il mio voto in questo caso, in quanto è un conflitto che l'utente può risolvere. Che l'esempio comune sia qualcos'altro non ha importanza per me, esistono altri esempi come questo. '400' ha ragione, ma c'è qualcosa da dire per '405' se usi le richieste' DELETE' ... Se no, 409 dico, ma se lo fai ... Vedo il tuo dilemma. – Wrikken

+0

Sì, sto usando il verbo DELETE qui, ma penso che 405 indichi che il metodo non dovrebbe essere permesso alla risorsa data. –

risposta

7

La chiave è guardare le aspettative sul client e le cache quando viene utilizzato un particolare codice di stato.

Ecco alcuni pezzi di RFC2616 che sono utili per guardare:

10.4.1. 400 Bad Request

La richiesta non è stata compresa dal server a causa di una sintassi errata. Il cliente NON DOVREBBE ripetere la richiesta senza modifiche.

Ciò indica che la richiesta stessa è completamente sbagliata, sintatticamente o dal protocollo. Il tuo caso specifico è in realtà un errore del protocollo dell'applicazione, quindi potrebbe essere appropriato.

10.4.6. 405 Metodo non consentito

Il metodo specificato nella Riga di richiesta non è consentito per la risorsa identificata dall'URI di richiesta. La risposta DEVE includere un'intestazione Consenti contenente un elenco di metodi validi per la risorsa richiesta.

Questo è un codice di stato transitorio. Se lo DELETE si riferisce specificamente alle risorse di contatto (ad esempio, DELETE /contacts/D9DF5176-EEE4-4C70-8DA7-BA57B82027A8), questo è probabilmente il codice di stato più appropriato. Tuttavia, se lo DELETE si trova su una risorsa diversa o una risorsa con una query (ad es., DELETE /contacts?index=12), quindi non restituirei un 405. Di nuovo, di solito evito di utilizzare DELETE con qualcosa che assomiglia a una query.

10.4.10. 409 Conflitto

Impossibile completare la richiesta a causa di un conflitto con lo stato corrente della risorsa. Questo codice è consentito solo in situazioni in cui è previsto che l'utente possa risolvere il conflitto e inviare nuovamente la richiesta. Il corpo della risposta DOVREBBE includere informazioni sufficienti per l'utente a riconoscere l'origine del conflitto. Idealmente, l'entità di risposta includerebbe informazioni sufficienti per l'utente o l'agente utente per risolvere il problema; tuttavia, ciò potrebbe non essere possibile e non è richiesto.

Questo sembra lo stato più appropriato al primo sguardo. Probabilmente preferirei un 400 nel tuo caso. Un 409 indica chiaramente che esiste un conflitto con la risorsa, ma in realtà non c'è nulla che il richiedente possa fare in grado di modificare l'esito a meno di alterare completamente la risorsa (ad esempio, aggiungere prima un contatto). La maggior parte delle 409 risposte erano errori di concorrenza ottimistici, come provare a modificare una risorsa che era stata modificata da quando è stata recuperata. Ad esempio, guarda lo concurrency failures returned by AtomServer built over Apache Adbera.

Quindi con tutto questo. Probabilmente userò qualcosa come 400 Cannot Delete Last Contact come linea di risposta. Ricorda che ti è permesso cambiare la frase associata al codice di stato. Questo è davvero un buon momento per fare una cosa del genere.

+0

Grazie per l'input D.Shawley, la ragione per cui sono titubante a utilizzare 400 è perché la definizione specifica "causa di sintassi errata". Sembra che tu stia ampliando questa definizione per includere il protocollo dell'applicazione. Avete riferimenti che supportano tale interpretazione? –

+0

Si dice anche che il metodo non consentito è transitorio. Nel mio caso, ogni contatto è la sua risorsa, quindi ognuno di essi ha un proprio Uri, quindi con il tuo argomento potrei usare questo codice. Tuttavia, la definizione di questo codice di stato non indica in realtà che sia transitoria. Ritorna questo stato per risorse che non possono essere cancellate, cioè la risorsa client stessa. –

+0

Ok, dopo aver discusso con alcuni colleghi abbiamo deciso di andare con 405. Segnalo come la risposta corretta perché è stato utile per aiutarci a decidere. Grazie per il tuo aiuto. –

Problemi correlati