KAHIBARO
Discord Login Register ☰
☰

GET Requests

Table of Contents

Understanding GET Requests

In REST APIs, GET is the most common HTTP method. It is used to retrieve data from the server without changing anything on the server.

This chapter focuses only on GET in the context of REST, not on other HTTP methods or full REST design, which are covered in separate chapters.

Key idea:
GET requests retrieve data and must not change server state.
They should be safe and idempotent.

What a GET Request Is For

A GET request asks the server:

"Give me the representation of this resource."

Examples of what you might fetch with GET:

In REST, typical GET endpoints might look like:

In all these examples, you are reading information.

Typical RESTful GET Patterns

EndpointMeaning
GET /resourcesList or search resources
GET /resources/{id}Get one resource by ID
GET /users/meGet information about the current authenticated user
GET /statsRead-only statistics or summary information

Where GET Data Goes: URL, Path, Query

A GET request does not usually send a request body in REST APIs. Data is typically sent in:

  1. The path
    • Example: /users/42
    • 42 is a path parameter.
  2. The query string
    • Example: /users?country=US&status=active&page=2
    • country, status, page are query parameters.

Example: Path vs Query in GET

Typical usage:

You will see path parameters and query parameters in much more detail in dedicated chapters, but for GET requests the key idea is:

Rule:
Use the path to point at what you want, and use the query string to refine how you want it.

GET Request Examples

Simple GET Request

Request:

http 
GET /users/42 HTTP/1.1
Host: api.example.com
Accept: application/json

Typical response:

http 
HTTP/1.1 200 OK
Content-Type: application/json
{
  "id": 42,
  "name": "Alice",
  "email": "alice@example.com"
}

GET With Query Parameters

Request:

http 
GET /products?category=books&sort=price_asc&page=1&limit=10 HTTP/1.1
Host: api.example.com
Accept: application/json

Typical response:

http 
HTTP/1.1 200 OK
Content-Type: application/json
{
  "items": [
    {
      "id": 101,
      "title": "Learn Backend Development",
      "price": 29.99
    },
    {
      "id": 102,
      "title": "Advanced REST APIs",
      "price": 34.99
    }
  ],
  "page": 1,
  "limit": 10,
  "total": 57
}

Here the query parameters control filtering, sorting, and pagination, which are covered more deeply in later chapters.

GET and RESTful URLs

In the chapter on RESTful URL design you will see general rules, but here are examples focused only on GET:

OperationRecommended GET URL
List all usersGET /users
Get one userGET /users/{user_id}
Get all posts for a userGET /users/{user_id}/posts
Get one post of a userGET /users/{user_id}/posts/{post_id}
Search users by name and countryGET /users?name=alice&country=US
Get paginated list of productsGET /products?page=2&limit=50
Get filtered, sorted productsGET /products?category=shoes&sort=-price

Notice that all of these are reads. No creation, updates, or deletions are done with GET.

Safety and Idempotency of GET

Two important properties of GET:

Safe

A method is safe if it does not change server state.

GET should be used only for reading. For example:

If a GET request changes your database, that is usually a design problem.

Idempotent

A method is idempotent if making the same request many times has the same effect as making it once.

For GET:

Design rule:
GET must be safe and idempotent. Do not use GET to create, modify, or delete data.

GET Request Body: Should You Use It?

The HTTP standard allows a body in a GET request, but in practice:

In REST APIs for backend development, it is a strong convention to not use a body for GET.

Use:

GET and Caching

GET works very well with caching, which is one reason it must be safe.

Because GET does not modify data, intermediate systems such as:

can cache responses and reuse them.

You will learn HTTP caching in detail in a separate chapter, but for GET:

Example:

http 
GET /products/123 HTTP/1.1
Host: api.example.com
Accept: application/json

Response:

http 
HTTP/1.1 200 OK
Content-Type: application/json
Cache-Control: max-age=60
{
  "id": 123,
  "name": "Wireless Mouse",
  "price": 19.99
}

The header Cache-Control: max-age=60 tells caches they can reuse this response for 60 seconds.

Practical hint:
If your endpoint changes data, do not use GET. If something uses GET, design it so it can be safely cached.

Common GET Status Codes

When you handle GET requests in a REST API, you usually return:

Status codeMeaningWhen to use for GET
200 OKSuccess with a response bodyResource found and returned
204 No ContentSuccess with no bodyRequest succeeded but nothing to return
301/302RedirectResource moved or redirect to another URL
400 Bad RequestClient error, invalid inputQuery parameters invalid
401 UnauthorizedNot authenticatedAuthentication required
403 ForbiddenNot allowedAuthenticated but not allowed
404 Not FoundResource does not existNo resource with that ID or URL
500 Internal Server ErrorServer errorSomething went wrong on the server

You will study status codes more deeply in the dedicated chapter, but for GET it is helpful to recognize:

Example:

http 
GET /users/999999 HTTP/1.1
Host: api.example.com
Accept: application/json
http 
HTTP/1.1 404 Not Found
Content-Type: application/json
{
  "detail": "User not found"
}

GET in a Simple REST API: Practical Examples

To make GET concrete, here are example designs for a small REST API.

1. Users API

OperationMethodURLRequest bodyResponse body
List usersGET/usersNoneList of users
Get user by IDGET/users/{id}NoneSingle user
Search users by nameGET/users?name=…NoneFiltered list

Example requests:

http 
GET /users HTTP/1.1
Host: api.example.com
Accept: application/json
http 
GET /users/42 HTTP/1.1
Host: api.example.com
Accept: application/json
http 
GET /users?name=alice&page=2 HTTP/1.1
Host: api.example.com
Accept: application/json

2. Products API

OperationMethodURL
List productsGET/products
Filter products by categoryGET/products?category=electronics
Filter and sortGET/products?category=electronics&sort=price_desc
Get single productGET/products/{product_id}
Get reviews for a productGET/products/{product_id}/reviews

Example GET for a list:

http 
GET /products?category=electronics&sort=price_desc&page=1&limit=20 HTTP/1.1
Host: api.example.com
Accept: application/json

Example GET for a single resource:

http 
GET /products/987 HTTP/1.1
Host: api.example.com
Accept: application/json

Common Mistakes to Avoid with GET

1. Using GET to Modify Data

Bad design:

These change data but use GET.

Better:

2. Putting Sensitive Data in the URL

Avoid sending sensitive information in query parameters, for example:

http 
GET /login?email=alice@example.com&password=secret

Problems:

Sensitive data such as passwords, tokens, or personal information should not be sent in GET query strings.

3. Overly Complex Query Parameters

Sometimes people try to encode very complex filters in a single query string parameter, for example:

http 
GET /search?filter=(status='active' AND age>18) OR city='London'

This becomes hard to parse and maintain. In many simple cases you can split it:

http 
GET /users?status=active&min_age=18&city=London

For very complex queries you might prefer:

How GET Is Used by Browsers and Tools

Browsers

When you:

the browser sends a GET request.

Example:

You enter https://example.com/products?category=books

The browser sends:

http 
GET /products?category=books HTTP/1.1
Host: example.com

HTML and GET

An HTML form without a method uses GET by default:

html 
<form action="/search">
  <input name="q" placeholder="Search">
  <button type="submit">Search</button>
</form>

If you type "backend" and submit, the browser sends:

http 
GET /search?q=backend HTTP/1.1
Host: example.com

This is why search engines often use URLs like:

https://www.google.com/search?q=backend+development

Designing Good GET Endpoints in REST APIs

When you design GET endpoints for a REST API, keep these practical guidelines in mind:

  1. Use nouns, not verbs, in URLs
    • Good: GET /users/42
    • Bad: GET /getUser?id=42
  2. Use plural resource names for collections
    • GET /users
    • GET /products
  3. Support filtering and pagination with query parameters
    • GET /products?category=books&page=2&limit=20
  4. Return appropriate status codes
    • 200 OK when data is found
    • 404 Not Found when the resource does not exist
    • 400 Bad Request when parameters are invalid
  5. Do not require a body
    • All needed input should be in the path or query string
  6. Keep them read-only
    • Never create, update, or delete data with GET

Summary

In later chapters you will learn in more detail how GET interacts with pagination, filtering, sorting, and how to implement GET endpoints in a specific framework such as FastAPI.

Views: 7

Comments

Please login to add a comment.

Don't have an account? Register now!

© 2025 Kahibaro
Visitors: 3105 / 24h
Impressum / Imprint
Datenschutz / Data Policy