Domanda API REST che utilizza POST anziché GET


Supponiamo che un servizio offra alcune funzionalità che posso usare in questo modo:

GET /service/function?param1=value1&param2=value2

È giusto dire che posso usarlo con una query POST?

POST /service/function { param1 : value1, param2 : value2 }

Queste due domande sono le stesse? Posso usare la seconda variante in ogni caso o la documentazione dovrebbe dire esplicitamente che posso usare sia le query GET che POST?


44
2017-10-28 14:30


origine


risposte:


Non puoi usare il API utilizzando POST o GET se non sono costruiti per chiamare usando questi metodi separatamente. Come se la tua API dicesse

/service/function?param1=value1&param2=value2

è accessibile usando GET metodo. Quindi non puoi chiamarlo usando POST metodo se non è specificato come POST metodo dal suo creatore. Se lo fai, potresti averlo 405 Method not allowed stato.

Generalmente in POST metodo è necessario inviare il contenuto nel corpo con il formato specificato che è descritto in content-type intestazione per es. application/json per dati json.

E dopo questo il corpo della richiesta viene deserializzato alla fine del server. Quindi è necessario passare i dati serializzati dal client e viene deciso dallo sviluppatore del servizio.

Ma in termini generali GET viene utilizzato quando il server restituisce alcuni dati al client e non ha alcun impatto sul server laddove POST è usato per creare alcune risorse sul server. Quindi generalmente non dovrebbe essere lo stesso.


29
2017-10-28 14:35



Solo per recensire, REST ha alcune proprietà che uno sviluppatore dovrebbe seguire per realizzarlo RESTful:

Cos'è REST?

Secondo wikipedia:

Lo stile architettonico REST descrive i seguenti sei vincoli   applicato all'architettura, pur lasciando l'implementazione del   singoli componenti liberi di progettare:

  • Client-server: I server non sono interessati all'interfaccia utente o allo stato utente, quindi i server possono essere più semplici e scalabili.
  • Stateless: La comunicazione client-server è ulteriormente limitata dal fatto che nessun client venga memorizzato sul server tra le richieste.
  • cacheable: Le risposte devono, implicitamente o esplicitamente, definirsi come memorizzabili nella cache o no, per impedire ai clienti di riutilizzare dati obsoleti o inappropriati in risposta a ulteriori richieste.
  • Sistema a strati: Un cliente non può normalmente dire se è collegato direttamente al server finale o ad un intermediario lungo la strada. I server intermedi possono migliorare la scalabilità del sistema abilitando il bilanciamento del carico e fornendo cache condivise.
  • Codice su richiesta (opzionale): I server possono estendere o personalizzare temporaneamente la funzionalità di un client mediante il trasferimento del codice eseguibile.
  • Interfaccia uniforme: L'interfaccia uniforme tra client e server, discussa di seguito, semplifica e disaccoppia l'architettura, consentendo a ciascuna parte di evolvere in modo indipendente. (cioè HTTP GET, POST, PUT, PATCH, DELETE)

Cosa dovrebbero fare i verbi

SO utente Daniel Vasallo ha fatto un buon lavoro nel definire le responsabilità di questi metodi nella domanda Informazioni su REST: verbi, codici di errore e autenticazione:

Quando si ha a che fare con un URI di raccolta come: http://example.com/resources/

OTTENERE: Elenca i membri della raccolta, completa con il loro membro   URI per ulteriore navigazione. Ad esempio, elenca tutte le auto in vendita.

METTERE: Significato definito come "sostituire l'intera collezione con un'altra   collezione".

INVIARE: Creare una nuova voce nella raccolta in cui è stato assegnato l'ID   automaticamente dalla raccolta. L'ID creato è solitamente incluso come   parte dei dati restituiti da questa operazione.

ELIMINA: Significato definito come "elimina l'intera collezione".

Quindi, per rispondere alla tua domanda:

È giusto dire che posso usarlo con una query POST? ...

Queste due domande sono le stesse? Posso usare la seconda variante in ogni caso o la documentazione dovrebbe dire esplicitamente che posso usare sia le query GET che POST?

Se stavate scrivendo una semplice chiamata API RPC vecchia, potevano tecnicamente intercambiabile finché il lato del server di elaborazione non era diverso tra le due chiamate. Tuttavia, affinché la chiamata sia RESTful, chiamare l'endpoint tramite GET il metodo dovrebbe avere una funzionalità distinta (che è quella di ottenere risorse (s)) dal POST metodo (che è quello di creare nuove risorse).

Nota a margine: c'è qualche dibattito là fuori sul fatto o meno POST dovrebbe anche essere permesso di essere usato per aggiornare le risorse ... anche se non sto commentando, vi sto solo dicendo che alcune persone hanno un problema con quel punto.


45
2017-10-28 19:01



Uso il corpo POST per qualsiasi app non banale e di linea di business per questi motivi:

  1. Sicurezza: se utilizziamo GET con stringhe di query e https, le stringhe di query possono essere salvate nei log del server e inoltrate come link di riferimento. Entrambi questi sono ora visibili da amministratori di server / network e il dominio successivo a cui l'utente è andato dopo aver lasciato la tua app. Pertanto, se inviamo una query contenente dati personali PII come il nome di un cliente, ciò potrebbe non essere desiderato.
  2. Lunghezza massima URL: non è un grosso problema, ma alcuni browser hanno un limite di lunghezza. Quindi, se nella nostra url sono presenti più voci come query, paging, campi da restituire, ecc ....
  3. Post non è cache per impostazione predefinita. Alcuni dicono che il caching è desiderato; tuttavia, quanto spesso lo stesso identico insieme di criteri di ricerca per quell'oggetto esatto per quel cliente esatto si verificherà prima che la cache scada comunque?

A proposito, ho anche messo i campi per tornare nel mio corpo POST come non vorrei esporre i miei nomi di campo. La sicurezza è come una cipolla; molti strati e ci fa piangere!


26
2018-02-16 23:24



Pensaci. Quando il tuo cliente fa una richiesta GET a un URI X, quello che sta dicendo al server è: "Voglio una rappresentazione della risorsa situata in X, e questa operazione non dovrebbe cambiare nulla sul server." Una richiesta PUT sta dicendo: "Voglio che tu sostituisca qualunque sia la risorsa che si trova in X con la nuova entità che ti sto dando sul corpo di questa richiesta". Una richiesta DELETE sta dicendo: "Voglio che tu cancelli qualunque sia la risorsa che si trova in X". Un PATCH sta dicendo "Ti sto dando questo diff, e dovresti provare ad applicarlo alla risorsa su X e dirmi se ha successo." Ma un POST sta dicendo: "Ti sto inviando questi dati subordinati alla risorsa in X, e abbiamo un precedente accordo su cosa dovresti fare con esso."

Se non lo hai documentato da qualche parte che la risorsa si aspetta un POST e fa qualcosa con esso, non ha senso inviare un POST a questo aspetto aspettandosi che si comporti come un GET.

REST si basa sul comportamento standardizzato del protocollo sottostante e il POST è precisamente il metodo utilizzato per un'azione non standardizzata. Il risultato di una richiesta GET, PUT e DELETE è chiaramente definito nello standard, ma POST no. Il risultato di un POST è subordinato al server, quindi se non è documentato che puoi usare POST per fare qualcosa, devi presumere che non puoi.


7
2017-11-02 19:59



In REST, ogni verbo HTTP ha il suo posto e il suo significato.

Per esempio,

  • GET è quello di ottenere la 'risorsa (s)' che è indicata nell'URL.

  • POST è di istruire il back-end per 'creare' una risorsa del 'tipo' puntata nell'URL. È possibile integrare l'operazione POST con parametri o dati aggiuntivi nel corpo della chiamata POST.

Nel tuo caso, dal momento che sei interessato a "ottenere" le informazioni usando la query, quindi dovrebbe essere un'operazione GET invece di un'operazione POST.

Questo wiki può aiutare per chiarire ulteriormente le cose.

Spero che questo aiuto!


2
2017-10-28 16:12



È bello che REST porti un significato ai verbi HTTP (così come sono definiti) ma preferisco essere d'accordo con Scott Peal.

Qui c'è anche un articolo tratto dalla spiegazione estesa di WIKI Richiesta POST:

Ci sono momenti in cui HTTP GET è meno adatto anche per il recupero dei dati. Un esempio di questo è quando una grande quantità di dati dovrebbe essere specificata nell'URL. Browser e server Web possono avere limiti sulla lunghezza dell'URL che gestiranno senza troncamenti o errori. La codifica percentuale dei caratteri riservati negli URL e nelle stringhe di query può aumentare significativamente la loro lunghezza e, mentre Apache HTTP Server può gestire fino a 4000 caratteri in un URL, [5] Microsoft Internet Explorer è limitato a 2048 caratteri in qualsiasi URL. [6] Allo stesso modo, HTTP GET non dovrebbe essere utilizzato quando le informazioni sensibili, come i nomi utente e le password, devono essere inviate insieme ad altri dati per la richiesta di completamento. Anche se si utilizza HTTPS, evitando che i dati vengano intercettati durante il transito, la cronologia del browser e i registri del server Web conterranno probabilmente l'URL completo in testo in chiaro, che potrebbe essere esposto se un sistema viene violato. In questi casi, è necessario utilizzare HTTP POST. [7]

Posso solo suggerire al team REST di prendere in considerazione un uso più sicuro del protocollo HTTP per evitare di far lottare i consumatori con "buone pratiche" non sicure.


-2
2017-11-01 23:46