Quali ragioni ci sono CONTRO utilizzando solo verbo POST HTTP in un'API?

6

Sto facendo ricerche prima di iniziare a lavorare su un'API per un servizio web che sto creando. L'obiettivo è di essere molto veloce e facile da adattare e utilizzare per altri sviluppatori, ma abbastanza nascosto per i clienti che utilizzano una raccolta di Webapp per effettuare chiamate al servizio dietro l'API.

È la prima volta che crei un'API per qualcosa di più che l'uso interno e ora mi sto chiedendo di ricercare gli standard là fuori se dovessi seguire RESTful raccomandazioni o piuttosto basta andare (il mio istinto) con POST Requests e un corpo JSON che contiene tutte le informazioni necessarie.

Il mio ragionamento sull'utilizzo di GET / HTTP-Verbs :

  • Il servizio ha abbastanza controllo di lettura / scrittura a grana fine per ogni singolo elemento Utente e DB. Quindi, anche una semplice richiesta LIST deve essere verificata non solo per le credenziali, ma deve fare una serie di procedure di convalida interne per vedere se il cliente è autorizzato a porre queste domande per questa particolare parte di dati.
  • implementazione facile : durante la codifica di solito sono felice di non dover saltare tra GET Url e corpi POST o PUT per ottenere il mio payload JSON sulla linea. Aggiungendoli all'URL se si tratta di una richiesta GET o nel corpo se si tratta di un POST o di un PUT. Quindi non sembra una seccatura andare con il POST. ma vedo che è molto il mio gusto personale piuttosto che vero per tutti - sono solo dannatamente pigro; -)
  • non è un punto valido perché usiamo SSL in ogni caso, ma link suggerisce che, almeno in teoria, potrebbe essere un po 'più sicuro non forzare troppe cose sensibili nell'URL. In particolare, se anche le richieste READ / LIST sono considerate sensibili per un servizio, ci si sente almeno un po 'strani a operare all'interno dell'URL.

il mio ragionamento per l'utilizzo di GET / HTTP-Verbs :

  • Compatibilità : gli standard sono fantastici. E le API RESTful sembrano ancora le più comuni. GET può essere facilmente testato o utilizzato dai client da un browser (non è sicuro se sia davvero un vantaggio, ma potrebbe risultare come uno)
  • RESTful mi costringe a una separazione dei problemi a grana fine attraverso non solo l'URL ma anche i verbi HTTP (GET / POST / PUT, ecc.). Solo usando POST I potrei fare lo stesso attraverso l'URL o l'analisi iniziale di JSON.
  • questo blogpost spiega un po 'i problemi, ho trovato molto utile

Esistono altri validi motivi per utilizzare l'intera varietà di verbi HTTP come, per esempio, i principi REST suggerirebbero?

Non riesco a trovare alcuna API che non usi diversi verbi HTTP. Quindi immagino che ci debbano essere delle ragioni molto forti per questo. Sospetto che i motivi menzionati nel blogpost siano i più rilevanti, ma mi chiedo se ci sia dell'altro e se ci sia sono altre soluzioni oltre a quella proposta lì (prima POST, quindi servendo una nuova risorsa GETable e restituendo l'URL)

Nota

questa domanda è simile alla mia ma proviene da un angolo leggermente diverso: È brutto usare il POST solo su un'API?

    
posta gauguerilla 11.09.2018 - 11:50
fonte

3 risposte

9

"Quali sono i motivi CONTRO di utilizzare solo verbo HTTP POST in un'API?"

Hai risposto alla tua domanda:

The goal is to be very quick and easy to adapt and use for other developers...

Se il tuo obiettivo è che altri sviluppatori comprendano rapidamente e utilizzino la tua API, utilizza gli standard che la maggior parte degli sviluppatori si aspetterebbe. È così semplice.

Per esaminare i motivi per cui usi POST:

  • Penso che sarebbe molto strano per un'operazione di lista usare il POST
  • La tua pigrizia nell'implementazione dell'API avrà un costo diretto quando altri sviluppatori inizieranno a utilizzarlo e si chiederanno perché ogni operazione richieda POST
  • Eventuali rischi di sicurezza ipotetici nell'uso di GET sono di gran lunga superati dagli argomenti per gli standard

Se vuoi sperimentare con un'API che solo tu userai, quindi sentiti libero di fare ciò che desideri. Ma se vuoi che altri sviluppatori lo usino, per favore risparmiaci la frustrazione e usa solo gli standard.

    
risposta data 11.09.2018 - 13:18
fonte
3

Le richieste GET dovrebbero essere idempotenti se le utilizzi per postare la data in cui verrà violato e inaspettato dagli utenti della tua API.

    
risposta data 11.09.2018 - 13:17
fonte
0

Se vuoi semplificare le cose agli sviluppatori che usano la tua API, non preoccuparti della RESTfulness dei vari verbi.

Pubblica un cliente

    
risposta data 13.09.2018 - 00:06
fonte

Leggi altre domande sui tag