Quali chiamate REST PUT / POST / DELETE devono essere restituite da una convenzione?

153

Secondo l '"ideologia REST" quale dovrebbe essere l'organismo di risposta per le richieste PUT / POST / DELETE?
Che dire dei codici di ritorno? È HTTP_OKabbastanza?
Qual è la ragione di tali convenzioni, se ce ne sono?

Ho trovato un buon post che descrive le differenze POST / PUT: POST vs PUT Ma non risponde ancora alla mia domanda.

— tuxSlayer
fonte

130

Perdona la debolezza, ma se stai eseguendo REST su HTTP, RFC7231 descrive esattamente quale comportamento è previsto da GET, PUT, POST e DELETE.

Aggiornamento (3 luglio 14):
Le specifiche HTTP non definiscono intenzionalmente ciò che viene restituito da POST o DELETE. La specifica definisce solo ciò che deve essere definito. Il resto è lasciato all'attuatore per scegliere.

— Darrel Miller
fonte

9

@tuxslayer Sono contento che tu non pensassi che stavo solo cercando di essere snarky. Molte persone sembrano pensare che REST aggiunga requisiti di aggiunta oltre ai metodi HTTP. Tuttavia, non è così. Esistono ulteriori vincoli, ma non incidono sul comportamento dei metodi HTTP. RFC2616 è sicuramente la guida da seguire.

— Darrel Miller,

4

Apprezzo il link. :) Mi ha fatto fermare e pensare allo strumento che sto usando. Dopo aver letto il tuo post e la RFC, mi sono ritrovato a fare riferimento alla RFC per il resto della notte. Mi ha aiutato a pensare prima al processo come a un processo HTTP e poi a un processo di riposo. Molto apprezzato.

— Perry Tew,

4

@PerryTew Ora puoi andare qui tools.ietf.org/wg/httpbis e vedere la versione attualmente in fase di revisione delle specifiche HTTP. Godere!

— Darrel Miller,

12

Forse ho solo bisogno di dormire di più, ma non riesco a trovare le informazioni esatte richieste dall'OP all'interno della RFC. Cosa dovrebbe essere il corpo per una risposta POST o DELETE?

— Cam Jackson

9

Bene, è chiaro come il fango. Forse alcune ulteriori informazioni nella risposta sarebbero utili. Soprattutto, quando quel collegamento è morto.

— Doug Molineux,

25

Nel complesso, le convenzioni sono "pensa che stai solo consegnando pagine web".

Per un PUT, restituirei la stessa vista che otterresti se facessi un GET subito dopo; ciò comporterebbe un 200 (beh, supponendo che il rendering abbia successo ovviamente). Per un POST, farei un reindirizzamento alla risorsa creata (supponendo che tu stia eseguendo un'operazione di creazione; in caso contrario, restituirei solo i risultati); il codice per una creazione riuscita è 201, che è in realtà l'unico codice HTTP per un reindirizzamento che non rientra nell'intervallo 300.

Non sono mai stato contento di ciò che un DELETE dovrebbe restituire (il mio codice attualmente produce un HTTP 204 e un corpo vuoto in questo caso).

— Donal Fellows
fonte

1

Avere la PUTrichiesta restituire la pagina successiva sembra una cattiva pratica, poiché l'aggiornamento sulla pagina risultante farà eseguire nuovamente la richiesta. Invece, per me ha senso fare un reindirizzamento, supponendo che tu abbia a che fare con richieste sincrone.

— lobati,

1

@lobati Penso che sia importante notare che l'invio di più richieste PUT identiche, dovrebbe avere esattamente lo stesso risultato dell'invio di una sola delle stesse richieste PUT. Forse il problema che sollevi ora è meno importante dato quanto sopra?

— Iain,

3

@Iain non proprio. Il problema è che se qualcos'altro aggiorna il record in un secondo momento, non vorrai che inviasse un'altra PUTrichiesta causando il ripristino dei dati. Ad esempio, se due persone fanno riferimento alla stessa pagina, una esegue un aggiornamento, quindi l'altra esegue un aggiornamento, se la prima persona si aggiorna per vedere il risultato, finirebbe effettivamente per ripristinare le cose prima che la seconda persona effettui i loro cambiamenti.

— lobati,

"Pensa come un sito Web" è perfetto, quindi un'eliminazione potrebbe rispondere con alcune probabili azioni successive, che dipendono dalla "storia" attorno al motivo per cui dovresti eliminare una risorsa. Questo potrebbe almeno essere un collegamento per riportare l'agente in un punto logico di inizio delle azioni o persino un reindirizzamento a una risorsa di stato che mostra l'impatto dell'eliminazione (totale dell'ordine) e contiene ulteriori collegamenti.

— Luke Puplett,

3

La creazione di una risorsa è generalmente mappata su POST e ciò dovrebbe restituire la posizione della nuova risorsa; ad esempio, in uno scaffold di Rails un CREATE reindirizzerà allo SHOW per la risorsa appena creata. Lo stesso approccio potrebbe avere senso per l'aggiornamento (PUT), ma è meno una convenzione; un aggiornamento deve solo indicare il successo. Una cancellazione probabilmente deve solo indicare anche il successo; se si desidera reindirizzare, restituire l'elenco delle risorse probabilmente ha più senso.

Il successo può essere indicato da HTTP_OK, sì.

L'unica regola rigida in quello che ho detto sopra è che un CREATE dovrebbe restituire la posizione della nuova risorsa. A me sembra un gioco da ragazzi; ha perfettamente senso che il cliente dovrà poter accedere al nuovo elemento.

— Jacob Mattison
fonte

2

In realtà hai confuso PUT e POST. POST viene utilizzato per la creazione, PUT viene utilizzato per l'aggiornamento (e la creazione). Vale anche la pena notare che PUT dovrebbe essere idempotente mentre POST non lo è.

— Stevie,

Un comando idempotente dovrebbe funzionare correttamente comunque molte volte lo si esegue. Quindi dovresti essere in grado di fare lo stesso PUT più volte per applicare lo stesso "aggiornamento" senza effetti collaterali negativi.

— Jacob Mattison,

1

Con RFC7231 non importa e può essere vuoto

Come implementiamo la soluzione basata su standard json api nel progetto:

post / put: restituisce gli attributi dell'oggetto come in get (filtro campo / relazioni applica lo stesso)

elimina: i dati contengono solo null (per la sua una rappresentazione di oggetto mancante)

stato per cancellazione standard: 200

— Marius Gri
fonte

0

Mi piace la risposta di Alfonso Tienda dal codice di stato HTTP per l'aggiornamento e l'eliminazione?

Ecco alcuni suggerimenti:

ELIMINA

200 (se si desidera inviare alcuni dati aggiuntivi nella risposta) o 204 (consigliato).

202 Operazione eliminata non è stata ancora impegnata.

Se non c'è nulla da eliminare, utilizzare 204 o 404 (l'operazione ELIMINA è idempotente, l'eliminazione di un elemento già eliminato ha esito positivo , pertanto è possibile restituire 204 , ma è vero che idempotente non implica necessariamente la stessa risposta)

Altri errori:

400 Richiesta errata (sintassi errata o query errata è strana ma possibile).

401 Errore di autenticazione non autorizzata

403 Proibito : errore di autorizzazione o ID applicazione non valido.

405 non consentito . Sicuro.

409 Il conflitto di risorse può essere possibile in sistemi complessi.

E 501 , 502 in caso di errori.

METTERE

Se stai aggiornando un elemento di una raccolta

200/204 con gli stessi motivi di ELIMINA sopra.

202 se l'operazione non è stata ancora eseguita.

L'elemento di riferimento non esiste:

PUT può essere 201 (se hai creato l'elemento perché quello è il tuo comportamento)

404 Se non si desidera creare elementi tramite PUT.

400 Richiesta non valida (sintassi non valida o query non valida più comune che nel caso di ELIMINA).

401 Non autorizzato

403 Proibito : autenticazione non riuscita o ID applicazione non valido.

405 non consentito . Sicuro.

409 Il conflitto di risorse può essere possibile in sistemi complessi, come in ELIMINA.

422 Entità non elaborabile Aiuta a distinguere tra "Richiesta non valida" (ad es. XML / JSON non valido) e valori di campo non validi

E 501 , 502 in caso di errori.

— Ryabchenko Alexander
fonte