Two pieces of the same web
Browsers and apps need two different kinds of answers:
- REST — what action to take on data (read, create, replace, change a part, delete).
-
DNS — which server on the internet owns a name like
www.instagram.com.
This post covers both. They do not depend on each other, but you meet them on almost every project.
REST API methods
A REST API exposes resources (users, orders, posts) at URLs. The HTTP method tells the server what to do with that resource.
| Method | Role | Typical use |
|---|---|---|
| GET | Read | Fetch data without changing it |
| POST | Create | Add a new resource |
| PUT | Replace | Swap the whole resource at that URL |
| PATCH | Partial update | Change some fields only |
| DELETE | Remove | Delete the resource |
All of these usually run over HTTPS on top of TCP.
GET — get the data
GET is for reading. It should not create, update, or delete on the server.
GET /students/345 HTTP/1.1
Host: api.example.com
The response might be JSON with the student’s name and section. Safe to retry: calling GET twice does not change the database.
POST — create
POST creates something new. The client sends a body; the server assigns an id and stores a new row.
POST /students HTTP/1.1
Content-Type: application/json
{"name": "Asha", "section": "B"}
POST is not for replacing an existing student in one shot. It is for adding a new record. POST is not idempotent: sending the same POST twice often creates two students unless the API has extra rules.
PUT — replace the whole resource
PUT means “here is the full new version at this URL.” If student 345 exists, PUT overwrites all fields you model at that URL. Missing fields might become empty or default, depending on the API design.
PUT /students/345 HTTP/1.1
Content-Type: application/json
{"name": "Asha", "section": "C"}
PUT is for replace, not “create with auto id” in the usual REST style. Some APIs allow PUT to create when the client chooses the id in the path; POST is still the usual way to create with a server-generated id.
PUT is idempotent: repeating the same PUT leaves the resource in the same state.
PATCH — replace part of the data
PATCH updates only what you send. Change the section without resending the whole student.
PATCH /students/345 HTTP/1.1
Content-Type: application/json
{"section": "C"}
Name and other fields stay as they were. Use PATCH when the client should not need to read the full object, change one field, and PUT everything back.
DELETE — delete the data
DELETE removes the resource at that URL.
DELETE /students/345 HTTP/1.1
After a successful delete, GET /students/345 might return 404 Not Found.
Quick comparison
POST → new resource (create)
GET → read (no change)
PUT → whole resource (full replace)
PATCH → part of resource (partial update)
DELETE → remove resource
DNS — Domain Name System
DNS (Domain Name System) turns hostnames people type into IP addresses computers use to connect. It is a distributed lookup system, not a single registry file on one machine.
When someone opens www.instagram.com:
- The browser asks the OS for that name.
- The OS asks a recursive resolver (often from your ISP or
8.8.8.8). - The resolver walks the DNS hierarchy — root →
.com→instagram.com→www— and finds a record such as an A record (IPv4) or AAAA (IPv6). - The browser opens HTTPS to that IP. TLS still checks the certificate matches
www.instagram.com.
user types www.instagram.com
|
v
DNS lookup -----> returns e.g. 157.240.x.x
|
v
TCP + TLS + HTTP to that server
Registering a domain (buying example.com) is a separate step from day-to-day DNS. A registrar records that you own the name. You (or your host) publish DNS records that say which IP or CDN serves www and mail. Those records live on authoritative name servers for your zone. The world’s resolvers cache answers for a while (TTL) so not every click hits the root.
Common record types:
| Record | Meaning |
|---|---|
| A / AAAA | Hostname → IP address |
| CNAME | Alias → another hostname |
| MX | Mail for the domain |
Without DNS, you would need to remember numeric IPs for every site. With DNS, you remember the name; the system routes you to the right server.
Side by side
| Topic | Question it answers |
|---|---|
| REST methods | What should the server do to this resource? |
| DNS | Which machine lives at this hostname? |
A mobile app might GET /feed on api.instagram.com. DNS is what resolved api.instagram.com before the GET ever left the phone.
Top comments (0)