The Method Dropdown and REST Semantics
Postman's method dropdown, located immediately to the left of the URL bar, lists GET, POST, PUT, PATCH, DELETE, HEAD, OPTIONS, and a few less common verbs. These correspond to the HTTP methods defined by the HTTP specification, and most REST APIs map them to CRUD operations: GET retrieves data without side effects, POST creates a new resource, PUT replaces an existing resource entirely, PATCH partially updates a resource, and DELETE removes it. Selecting a different method in Postman doesn't change the URL, but it does change which tabs become relevant — GET requests rarely need a Body tab, while POST, PUT, and PATCH almost always do.
Cricket analogy: It's like the different match formats — Test, ODI, T20 — that use the same sport but with different rules for scoring and duration, the way GET, POST, and DELETE use the same URL but with fundamentally different effects.
Sending POST and PUT Requests with a Body
When the method is POST, PUT, or PATCH, the Body tab becomes essential, offering options like none, form-data, x-www-form-urlencoded, raw, and GraphQL. For a JSON API, the standard choice is raw, with the format dropdown set to JSON, which also automatically sets the Content-Type header to application/json — a detail many beginners forget to set manually when using raw curl, causing the server to misinterpret the payload. Postman's Body editor supports full JSON syntax highlighting and will flag invalid JSON with a red warning icon before you even click Send, catching a missing comma or unclosed brace early.
Cricket analogy: It's like a bowler correctly gripping the seam before a delivery — set the ball (Content-Type) wrong and the swing (server interpretation) won't behave as intended, the way an inswing grip mistakenly bowled as outswing misleads the batsman.
PATCH vs PUT: Partial vs Full Updates
PUT and PATCH are both used to update an existing resource, but they carry different semantics that Postman doesn't enforce — it's up to the API and the developer to use them correctly. PUT conventionally expects the full representation of the resource in the body, meaning any field omitted may be treated as cleared or reset to a default. PATCH conventionally sends only the fields that changed, leaving everything else untouched on the server. Testing this distinction in Postman is straightforward: send a PUT with only a name field to an endpoint that also has an email field, then GET the resource afterward to see whether the email field survived — many APIs' actual behavior differs from the textbook definition, and Postman is the fastest way to find out empirically.
Cricket analogy: It's like the difference between a full team overhaul at a mega auction, replacing the entire XI, versus a single mid-season transfer window swap — PUT replaces the whole roster, PATCH swaps in just one player.
Postman's Code snippet generator (the </> icon on the right of the request builder) converts your current request, including method, headers, and body, into equivalent code in over a dozen languages and tools, including curl, Python's requests library, JavaScript's fetch, and Node's axios — useful for verifying exactly what Postman is sending under the hood.
Switching the method dropdown from POST to GET does not clear the Body tab's contents; the body remains configured but is typically ignored by servers for GET requests. If a GET request behaves unexpectedly, check whether a leftover body from a previous POST is still populated in the Body tab.
// POST https://api.example.com/v1/products
// Body -> raw -> JSON (Content-Type: application/json set automatically)
{
"name": "Wireless Mouse",
"price": 24.99,
"category": "electronics"
}
// Response: 201 Created
{
"id": 501,
"name": "Wireless Mouse",
"price": 24.99,
"category": "electronics",
"createdAt": "2026-07-10T09:15:00Z"
}- Postman's method dropdown supports GET, POST, PUT, PATCH, DELETE, HEAD, OPTIONS, and more.
- GET retrieves data without side effects; POST creates; PUT replaces fully; PATCH updates partially; DELETE removes.
- The Body tab is essential for POST, PUT, and PATCH, with raw/JSON being the standard choice for REST APIs.
- Choosing JSON as the raw body format auto-sets the Content-Type: application/json header.
- PUT conventionally expects the full resource representation; PATCH sends only changed fields.
- Actual API behavior for PUT vs PATCH can differ from convention, and Postman is the fastest way to verify it empirically.
- Postman's code snippet generator converts the current request into equivalent curl, Python, or JavaScript code.
Practice what you learned
1. Which HTTP method conventionally retrieves data without causing side effects?
2. What does selecting raw and JSON in Postman's Body tab automatically configure?
3. What is the conventional difference between PUT and PATCH?
4. Why might a GET request behave unexpectedly after being switched from a POST in Postman?
5. What does Postman's code snippet generator (the </> icon) do?
Was this page helpful?
You May Also Like
Making Your First Request
A step-by-step walkthrough of building and sending your first GET request in Postman, reading the response, and saving the request for reuse.
Request and Response Anatomy
A breakdown of the parts that make up an HTTP request (URL, headers, body) and response (status line, headers, body) as seen in Postman.
The Postman Interface
A tour of Postman's main workspace layout — sidebar, request builder, response viewer, and console — and how each panel supports the request-response workflow.