Welcome to the Treehouse Community

Want to collaborate on code errors? Have bugs you need feedback on? Looking for an extra set of eyes on your latest project? Get support with fellow developers, designers, and programmers of all backgrounds and skill levels here with the Treehouse Community! While you're at it, check out some resources Treehouse students have shared here.

Looking to learn something new?

Treehouse offers a seven day free trial for new students. Get access to thousands of hours of content and join thousands of Treehouse students and alumni in the community today.

Start your free trial

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

Mert Kahraman
Mert Kahraman
12,118 Points
Posted by Mert Kahraman
Mert Kahraman
12,118 Points

GET vs POST

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.

Thanks!

2 Answers

Alexander Nikiforov
seal-mask
.a{fill-rule:evenodd;}techdegree seal-36
Alexander Nikiforov
Java Web Development Techdegree Graduate 22,175 Points
Alexander Nikiforov
.a{fill-rule:evenodd;}techdegree seal-36
Alexander Nikiforov
Java Web Development Techdegree Graduate 22,175 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
seal-mask
STAFF
.a{fill-rule:evenodd;}techdegree
Chris Ramacciotti
Treehouse Guest Teacher
Chris Ramacciotti
.a{fill-rule:evenodd;}techdegree
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. :)