Client o server controlla se inserire o aggiornare nell'architettura RESTful

Question

Client o server controlla se inserire o aggiornare nell'architettura RESTful

#1 da (4 voti)
#2 da (3 voti)

1

Prima di iniziare a sviluppare un'API RESTful ho usato una query simile a questa:

$query = "INSERT INTO availability (user_id, date, status) " .
         "VALUES ('".$id."', '".$date."', '".$status."') " .
         "ON DUPLICATE KEY " .
         "UPDATE status='".$status."'";

Sì, so che è soggetto all'iniezione SQL. In ogni caso, ho difficoltà a decidere se questa dovrebbe essere una richiesta POST o PUT poiché può essere inserita o aggiornata. Ho pensato: forse è meglio avere entrambi i metodi POST e PUT nell'API e poi il client determina quale chiamare.

Questo è in genere il modo in cui le API RESTful gestiscono questo scenario?

php rest mysql

posta keelerjr12 11.07.2017 - 02:07

fonte

2 risposte

3

Potrebbe essere utile esaminare prima la differenza tra POST e PUT.

La differenza principale è che PUT è destinato alle operazioni idempotenti. Cioè, operazioni che possono essere eseguite più volte ma si comportano come se fossero eseguite una volta. POST non ha tale presupposto. Il significato dell'idempotenza è che il cliente o l'infrastruttura possono ripetere la richiesta se non sembra essere stata riconosciuta. Con una richiesta POST, ciò potrebbe causare conseguenze indesiderate. Questo è il motivo per cui il tuo browser ti avvisa se aggiorni una pagina che è stata prodotta tramite una richiesta POST.

L'operazione nella tua domanda è idempotente, quindi PUT può e deve essere usato. Una richiesta POST sarebbe appropriata per operazioni che non sono idempotenti come operazioni che assomigliano più a chiamate RPC o, più nello spirito di REST e HTTP, creando nuovi record. Ad esempio, se disponi di un campo ID di incremento automatico e ogni INSERT ha creato un nuovo record, utilizzerai il POST perché tale operazione non è idempotente: eseguendo due volte verranno creati due nuovi record.

risposta data 11.07.2017 - 02:32

fonte

Leggi altre domande sui tag php rest mysql

L'invio di parametri all'interno di una classe suggerisce che dovrei rifattore in una nuova classe? In che modo la documentazione Agile influisce sul Contratto e sulla Dichiarazione di lavoro iniziale?

score 4 · Accepted Answer

I got to thinking: maybe it's better to have both POST and PUT methods in the API and then the client determines which one to call.

Is this usually how RESTful APIs handle this scenario?

Non proprio. Pensa a come implementeresti questo in un sito web. Qualcuno andrebbe alla home page, quindi seguirà un link a un modulo che consentirà loro di fornire i dati che vorrebbero utilizzare, quindi invieranno il modulo e riceveranno un messaggio in cui si comunicherà se l'invio è andato a buon fine.

La rappresentazione del modulo descriveva l'identificativo della risorsa a cui inviare la richiesta e il metodo da utilizzare (in un modulo HTML, che sarebbe sempre un POST, ovviamente).

Quindi puoi usare POST, o PUT, o alternare avanti e indietro, o fare quello che vuoi semplicemente alterando la rappresentazione del modulo.

Da una prospettiva REST, l'unica cosa importante è rispettare l'interfaccia uniforme; che in questo caso significa che la semantica dei tuoi messaggi è allineata con le specifiche HTTP.

REST in realtà non si cura del metodo che si usa, purché (a) lo si usi correttamente secondo l'interfaccia uniforme, e (b) il client scopra quale metodo utilizzare consumando l'ipermedia fornita dal server.

Semanticamente, un PUT dovrebbe essere un sostituto completo. RFC 7231 è lo standard pertinente.

The PUT method requests that the state of the target resource be created or replaced with the state defined by the representation enclosed in the request message payload

È un po 'strano che tu inserisca $date ma non lo aggiorni. Non è sbagliato, ma è difficile capire dall'esempio se date fa parte della "rappresentazione racchiusa nel payload del messaggio di richiesta". La semantica di PUT consente a clienti e intermediari di formulare determinate ipotesi sullo stato della risorsa aggiornata senza inviare un GET al server: è responsabilità del server assicurarsi che tali ipotesi siano valide.