You can build a whole Laravel application without ever really thinking about what happens between the browser and your server. Until something breaks. Suddenly you're staring at a CORS error or a 419 page, and you have no idea where to start looking. In this blog post, we'll go through the basic concepts of the web that every developer runs into, sooner or later, and how they might show up in a Laravel application.
HTTP Requests And Responses
Everything on the web starts with a conversation. Your browser (the client) sends a request, and the server sends back a response. That's it. Every page you open, every image you load, and every API call you make is one of these.
A request contains a method, like GET, POST, etc., headers (Content-Type, etc.) and, depending on what type of method your request is, a body that contains, for example, the data of a form.
A response contains a status code, headers, and usually a body (like HTML or JSON).
Methods
The method tells your server what exactly you want to do. The most common ones are:
- GET: fetch some data or resource. It shouldn't change anything on the server.
- POST: create something new on the server, like submitting a registration form.
- PUT: replace a resource completely.
- PATCH: update only a part of a resource.
- DELETE: remove a resource.
It is important to make sure that the request type matches what you want to do. If you want to send information to your server, with the goal being to create a new resource, use POST. If you simply want to update some data of a resource, use PATCH. In Laravel, you can do this by adding an @method tag to your form. This will make so that whatever request type you put in there, is the request type used to transmit your form's data.
Response Codes
Status codes are the way your server tells your application how things went. They're grouped by their first digit:
- 2XX: everything went well.
- 3XX: the thing you're looking for is somewhere else. Redirect.
- 4XX: you (the client) did something wrong. Either you're not logged in (401), you tried to visit a destination that doesn't exist (404), etc.
- 5XX: the server did something wrong. This can be an unhandled exception, or worse, something wrong with another service, database, etc.
However, sometimes you don't actually want to show the client exactly what's going on. For example, if an unauthorized person wants to visit a page like yoursite.com/admin, while your page actually exists, this person should not know it does. So instead of sending them a 401 response (unauthorized), we let them know the page does not exist (even though it does).
Redirects
Sometimes the server doesn't want to give you the page, but wants to send you somewhere else. This is a redirect, and it's a 3xx response with a Location header that contains the new URL.
The two you should know are 301 (Moved Permanently) and 302 (Found). A 301 tells browsers and search engines that the page has moved for good, while a 302 says it's only temporary.
Headers
Headers are small pieces of information that travel alongside with every request and response. These key-value pairs are to give the client and/or server more information about the request/response, such as what type of content it bears (JSON, HTML, etc.), or even tokens for authentication, cookies, etc.
If your request has the Accept: application/json header, the server knows you're an API client, and knows that it should send back it's data in JSON format.
Cookies Vs. Sessions
These two get mixed up often, since they kind of work together.
A cookie is a small piece of data that is stored in the browser. After the server sets it with a Set-Cookie header, the browser sends it back with every request to that domain. They are about 4KB in size and live on the client. This means you shouldn't blindly trust cookies, since they can be manually edited by the client.
A session is data stored on the server. Think of things likes the logged in user, flash messages, etc. The browser doesn't get
