The Web, and Why Frameworks Exist
You type bookclub.example/books and a list of books appears. Between the key press and the page, a request crossed the internet, some code on a server decided what to send back, and your browser drew the result. Rails is a tool for writing that "some code" without reinventing every part of it.
The rule
A request asks, a response answers; the framework does the plumbing.
Every exchange on the web has two halves.
A request is the browser asking for something. Its core is a method and a path:
GET /books HTTP/1.1
Host: bookclub.exampleGET means "give me this"; POST means "here is new data"; PATCH and DELETE change or remove things. The path names what you want.
A response is the server's answer: a status code and usually a body.
HTTP/1.1 200 OK
Content-Type: text/html
<h1>Books</h1> ...200 means fine, 302 means "go over there instead", 404 means "no such page", and 500 means the server's own code crashed.
Now picture writing a server that handles this by hand. For every app you would write code to match paths to handlers, read form fields, talk to the database, escape HTML so users cannot inject scripts, remember who is logged in, and block forged form posts. Those jobs are the same in every app. A web framework is that shared plumbing, already written and tested. Rails adds strong conventions: if you name things the expected way, the pieces find each other with no configuration. That idea is called convention over configuration.
The shortcut
When you meet any web feature, split it in two: what every app needs (the framework's job) and what only this app needs (your job).
The request arrives
The browser sends
GET /books/7. Parsing that text is every app's problem, so Rails does it.
The trap is thinking a framework limits you. It removes only the repeated work; the decisions that make your app yours still live in your code.
Drills
Answer fast — trust the rule.
A browser submits a "new review" form. Which method does that request normally use?
The server's own code raises an error while building the page. Which status fits?
Which job is plumbing that Rails does for every app, rather than something only Bookclub needs?
What does "convention over configuration" mean in Rails?
Remember
- A request is a method plus a path; a response is a status plus a body.
- Split every feature into plumbing (Rails) and what is unique (you).
- Trap: a framework does not decide your app's rules; it only removes the repetition.