Welcome to the Treehouse Community

The Treehouse Community is a meeting place for developers, designers, and programmers of all backgrounds and skill levels to get support. Collaborate here on code errors or bugs that you need feedback on, or asking for an extra set of eyes on your latest project. Join thousands of Treehouse students and alumni in the community today. (Note: Only Treehouse students can comment or ask questions, but non-students are welcome to browse our conversations.)

Looking to learn something new?

Treehouse offers a seven day free trial for new students. Get access to thousands of hours of content and a supportive community. Start your free trial today.

Development Tools HTTP Basics Introduction to HTTP Sending Data with a POST Request

Mert Kahraman
Mert Kahraman
12,118 Points


In both GET and POST requests, aren't we passing a data of some sort? Hence why POST is considered as leading to a change on the server, but GET does not?

I would appreciate any help on this issue.


2 Answers

Alexander Nikiforov
.a{fill-rule:evenodd;}techdegree seal-36
Alexander Nikiforov
Java Web Development Techdegree Graduate 22,161 Points

I think it is just the way HTTP protocol is made:

If you make GET request on server you should not change anything on server.

If you make POST request, you should send information in body of request, or you should change something on server.

You have to follow the rules of protocol if you implement web application, which means don't change data with 'GET' and change data with POST request.

That can basically mean, if you have database, you should not change database with GET request. If you want to change it somehow, send POST, or PUT, DELETE if possible

Chris Ramacciotti
Chris Ramacciotti
Treehouse Guest Teacher

To add to the excellent answer offered by Alexander Nikiforov, one motivation for following the protocol is for caching purposes. Browsers and caching servers aren't configured to cache POST requests because they lead to a change in server state. However, they typically are configured to cache GET requests, with varied parameters for doing so. Cached requests lead to faster response times. If you make a change that the client will be held responsible for in a GET request, this violates the HTTP protocol, though no protocol enforcement agency prevents you from doing this. The problem is that a user can bookmark this request, and a server can cache the request, leading to unpredictable behavior and compromised data integrity.

For example, if you wrote an app configured to complete a purchase using app.example.com/purchase?itemId=543&creditCardNum=1234567887654321, then that request can be bookmarked, cached, and refreshed. Chances are that the purchaser and credit card holder wouldn't be happy about the ease with which the purchase could be repeated, not to mention their credit card number being displayed in the URL and cached in plain text, possibly on both the client and server.

Lots of software related to performance and security is built to make applications robust and responsive, and assumes that protocols are being followed. You can fully leverage all the benefits of this by following the protocol. That said, as you are astutely aware, you certainly can choose not to follow the protocol. :)