Interactive websites and apps need to do more than reading data from a server. To be useful, we also need to write or mutate, data.
If a user fills out a newsletter subscription form, we will need to update a database that adds them to a list.
When we request a website from our browser's URL bar, we are making a GET request to our server. But there are a few more types—or methods—of requests we can make.
When a user submits a newsletter subscription form, they are requesting to update some records. This is a classic POSTÂ request.
When a request is sent with the POST method, it will contain some data that the server can use to make the necessary changes.
That request will likely include headers to ensure that the request is authenticated and has permission to make those changes.
And just like with a GET request, the server will send a response.
The browser needs to know if the operation was successful.
If the request fails, the response should tell the browser why it failed so our next view can provide feedback to the user.
Challenge
Let's say a user is a clever developer. They fill out a form but decide to open up dev tools and change the method of the form from GET to POST. They are trying to write data that they may not have the right to update.
What should the server's response to the client look like in this case? What reason might we give for not allowing the change?
In a line of pseudo-code or a few sentences, respond here and let me know what you think.
