DOMANDA DA COLLOQUIO Una domanda che ho visto fare recentemente ad un colloquio, abbastanza semplice ma interessante: "Perché in un servizio REST dovremmo usare una POST invece di una GET?" La risposta riguarda la lunghezza dei dati: ✅ Una GET invia i dati nell’URL, che ha un limite (es. ≈2000 caratteri nei browser moderni) ✅ Una POST invia i dati nel body, senza limiti pratici rilevanti Piccola nota storica: in un passato non troppo lontano (che io ricordo), URL troppo lunghi hanno persino causato buffer overflow. Cioè, bastava una GET con un URL troppo lungo per corrompere la memoria e compromettere il sistema, eseguendo del codice arbitrario . Oggi ovviamente non è più così. EDIT Visto il numero di commenti (grazie!), aggiungo una piccola precisazione – anche perché non riesco a rispondere a tutti (maledetto lavoro 😅): Questa domanda è stata posta dopo aver discusso insieme i fondamenti di REST: cos'è una risorsa, le differenze tra GET/POST/PUT/DELETE, ecc. Solo dopo questa fase di confronto, è arrivata la domanda: "Ok, ma secondo te perché per prendere una risorsa REST usiamo una GET e non, ad esempio, una POST?" Mi è piaciuta perché non si è fermato alle definizioni ma ha spinto verso un ragionamento. E come tale, ha stimolato una risposta pensata, non solo “recitata”. #SoftwareEngineering #RESTAPI #Backend #Security #BufferOverflow #DevInterview #CleanCode
Oltre a tutto quanto detto relativamente ai servizi REST, aggiungerei che se mandi dati sensibili via GET rimangono anche "bookmarkabili" e visibili nella cronologia. Tuttavia, POST NON è più sicuro nel senso totale della parola, dato che i dati vengono inviati con il corpo della richiesta.
ce anche da aggiungere che POST è usato per creare nuove risorse o inviare dati al server per modificarne lo stato mentre GET è usato per recuperare dati
Piuttosto una demanda da esame piuttosto che per lavoro….
I dati sensibili non si mandano mai pee GET… se non hai intenzione di fare qualche acquisto con carte degli altri 👀👀
GET non invia dati li riceve. https://developer.mozilla.org/en-US/docs/Web/HTTP/Reference/Methods/GET
POST ha dei limiti imposti dalla configurazione del server.
A costo di sembrare spocchioso, cosa che non voglio essere, ho visto nei commenti una marea di affermazioni sbagliatissime che ho sentito propinare da quando ho iniziato a lavorare, e vorrei fare un attimo di chiarezza sulla questione. 1. I verbi HTTP fanno parte del protocollo HTTP per l'appunto, ed esistono a prescindere dalla questione ReST. Questo vuol dire che i verbi HTTP sono stati declinati nel protocollo con il preciso compito di assolvere a delle precise funzioni (GET per la lettura, POST per la creazione di una nuova risorsa, PUT per l'aggiornamento etc...). 2. POST non è più sicuro di GET. Chi afferma una cosa del genere dovrebbe tornarsene a studiare e di corsa, perché lavorare in questo ambito e non conoscere le basi del protocollo HTTPS è, a parer mio, gravissimo. Se si usa HTTP, i dati sono leggibili da chiunque si inserisca tra mittente e ricevente, mentre con HTTPS non viene cifrato soltanto il body ma l'URL, i query params, gli header ed i cookie. Le uniche parti che non vengono cifrate (non possono esserlo per questioni tecniche) sono il dominio e la porta. Ci tenevo, perché sono stanco (ma proprio sfinito) di leggere certi commenti che poi vengono presi pure per veri.
In un servizio REST dovremmo usare POST invece di GET quando l'operazione che stiamo eseguendo comporta una modifica dello stato del server, come la creazione o aggiornamento di una nuova risorsa. La ragione fondamentale è la semantica delle operazioni HTTP e quindi il concetto di idempotenza. Una richiesta GET è definita come idempotente per definizione. Al contrario, una richiesta POST non è idempotente. Ripetere una richiesta POST identica potrebbe, per esempio, creare più record uguali. Questo è il comportamento atteso per operazioni che hanno lo scopo di alterare lo stato del server. Oltre all'idempotenza, una POST offre maggiore flessibilità e sicurezza. I dati vengono inviati nel corpo della richiesta, permettendo di gestire grandi quantità di informazioni (ma non illimitate) che non sono visibili nell'URL come accade con una GET. In sintesi, scegliamo GET per leggere dati senza side effect e POST per scrivere o modificare dati, rispettando i principi RESTful per garantire la prevedibilità, la sicurezza e la correttezza del servizio.
💡 Founder | Flutter Enthusiast | EMBA Ambassador @ Polimi | Digital Transformation | Business Advisor
1 meseAntonio, si trattava di un esame universitario e/o per vedere se un junior ha fatto i compiti? o per uno sviluppatore un po' più maturo? Personalmente trovo la domanda è incompleta -> se la policy aziendale/team/progetto obbliga a progettare secondo legacy strict RESTful, farei prima leggere al candidato la documentazione di sistema (dove devono essere ripetute i perimetri obbligatori), farei un minicaso e gli chiederei uno sviluppo applicativo coerente. Giudicando quindi la reale capacità di allinearsi al team. Io non passerei il colloquio, non risponderei bene. La risposta che però vorrei sentire sarebbe tipo: - per REST non so esattamente che cosa intendi, GET non mi piace perché mi limita; ad esempio uso POST per loggare informazioni direttamente lato server, gestire il token con dati sensibili senza esporli nell'url (nonostante il layer di sicurezza sia sul protocollo https), evitare ripetute richieste automatizzate basati su parametri in linea, limitare problemi di cache aggressivi, ecc... Ovvero, non ti so rispondere, se non mi fornisci un contesto entro cui comprendere perché dovrei usare POST invece di GET. Sono specifiche di 25 anni fa. Non più universali. Hai presente la storia-leggenda del barometro di Niels Bohr?