DEV Community

Cover image for REST API methods and DNS, in one place
Tarang
Tarang

Posted on

REST API methods and DNS, in one place

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
Enter fullscreen mode Exit fullscreen mode

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"}
Enter fullscreen mode Exit fullscreen mode

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"}
Enter fullscreen mode Exit fullscreen mode

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"}
Enter fullscreen mode Exit fullscreen mode

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
Enter fullscreen mode Exit fullscreen mode

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
Enter fullscreen mode Exit fullscreen mode

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:

  1. The browser asks the OS for that name.
  2. The OS asks a recursive resolver (often from your ISP or 8.8.8.8).
  3. The resolver walks the DNS hierarchy — root → .com → instagram.com → www — and finds a record such as an A record (IPv4) or AAAA (IPv6).
  4. 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
Enter fullscreen mode Exit fullscreen mode

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)