Un'API ReST dovrebbe ignorare in silenzio la richiesta per modificare il campo inesistente?

Question

Considerare un'API ReST che fornisce un'interfaccia a un database.

Se il server risponde con una richiesta di HTTP 400 Bad Request su una richiesta PUT o PATCH che tenta di specificare un nuovo valore per una colonna che non esiste nel database? Il server dovrebbe ignorare silenziosamente l'errore? Il server dovrebbe fare qualcos'altro che non ho menzionato qui?

Answer 1

Se è possibile per il cliente di inviare nuovamente senza il valore aggiunto si dovrebbe rispondere con 409. dalla spec:

10.4.10 409 Conflitto

La richiesta non può essere completata a causa di un conflitto con lo stato attuale della risorsa . Questo codice è consentito solo in situazioni in cui si prevede che l'utente potrebbe essere in grado di risolvere il conflitto e inviare nuovamente la richiesta. Il corpo della risposta DOVREBBE includere abbastanza informazioni per l'utente per 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.

conflitti hanno più probabilità di verificarsi in risposta a una richiesta PUT. Per esempio , se il controllo delle versioni era in uso e se l'entità era PUT incluse le modifiche a una risorsa che sono in conflitto con quelle effettuate da una richiesta precedente (di terze parti), il server potrebbe utilizzare la risposta 409 per indicare che può ' t completare la richiesta. In questo caso, l'entità risposta sarebbe probabilmente contenere un elenco delle differenze tra le due versioni in un formato definito dalla risposta Content-Type.

Answer 2

Non silenziosamente ignorare la richiesta
io non sono sicuro di come si potrebbe in ogni caso, oltre al server di chiudere la connessione senza inviare una risposta.

400 è buono, come è 409. Si potrebbe anche prendere in considerazione 403 Forbidden: Il server capito la tua richiesta, ma si rifiuta di compierla.

400 è in genere per le richieste di mal-formata.
403 fa bene quando la richiesta è stata sufficientemente ben formata che il codice del server è stato in grado di analizzarlo e capire a cosa serviva la richiesta. Penso che la maggior parte soddisfi il tuo requisito qui.

Tuttavia, una linea nella tua domanda mi preoccupa:

tentativi di specificare un nuovo valore per una colonna che non esiste nel database

Le richieste non devono essere modificare i valori delle colonne in un database. Dovrebbero modificare il contenuto di una risorsa. I due non sono la stessa cosa. È facile cadere nella trappola di pensare "oh, lascia solo esporre questo oggetto dominio come una risorsa HTTP" ma ciò può causare problemi di scalabilità lungo la linea. In generale, dovresti avere più risorse nello spazio URI rispetto agli oggetti del modello. Ciò consente di memorizzare nella cache le parti abbastanza statiche del modello con una politica diversa rispetto a quelle molto più dinamiche.

Ad esempio, in un sistema di elaborazione degli ordini, l'indirizzo di consegna cambia molto di rado, ma il rilevatore di avanzamento potrebbe cambiare ogni pochi minuti. Dare ai due dati diversi URI e differenti criteri di cache.

Answer 3

Ignorare silenziosamente gli errori è una ricetta per rendere difficile l'utilizzo dell'API. A meno che tu non fornisca una documentazione estremamente buona (e talvolta anche allora) lo sviluppatore che sta lavorando su un client per la tua API difficilmente saprà che parti della loro richiesta potrebbero essere ignorate. Di conseguenza, è probabile che diventino confusi sul motivo per cui la risorsa non riflette ciò che hanno passato. Sprecare tempo alla gente in questo modo non renderà popolare la tua API.

Answer 4

Nella mia esperienza non dovresti ignorare silenziosamente altre proprietà e trattare PUT/POST come se non esistessero. Considera un consumatore che chiama un'API con proprietà facoltative nel modello. Se il consumatore dell'API ha un errore di battitura nel nome di una proprietà facoltativa, l'API risponderà con un 200 e il consumatore richiederà un tempo di debugging considerevolmente maggiore rispetto a un 400 restituito. Spesso i bug più frustranti derivano da errori di battitura innocenti come "laed" invece di "lead".