Definition
GET is the most common HTTP method - it retrieves data from a server. When you type a URL into your browser, visit a webpage, or load an image, your browser sends GET requests. GET means “give me this resource” without changing anything on the server.
GET is both safe (no side effects - reading doesn’t modify data) and idempotent (calling it multiple times has the same effect as calling it once). This makes GET requests perfect for caching, bookmarking, and refreshing.
GET requests should never modify server state. Parameters go in the URL query string (/users?role=admin), not in a request body. The response can be cached by browsers and intermediaries, making GET the most performant HTTP method.
Example
Web Browsing: When you visit https://example.com, your browser sends GET / HTTP/1.1. The server returns the homepage HTML.
API Data Fetching: Weather app sends GET /api/weather?city=NYC to retrieve current weather. The city parameter is in the URL.
Image Loading: Every image on a webpage requires a GET request. <img src="/logo.png"> triggers GET /logo.png.
Search Results: Google uses GET for searches: GET /search?q=http+methods. The query is in the URL, so you can bookmark or share the link.
Pagination: Listing blog posts with GET /posts?page=2&limit=10 retrieves the second page of results.
Analogy
Library Card Catalog: Using GET is like looking up books in a library catalog - you’re just reading information, not checking out books or changing the library’s inventory. You can look at the same entry a hundred times without affecting anything.
Restaurant Menu: Reading a menu is a GET request - you’re gathering information without placing an order. The menu doesn’t change because you looked at it.
ATM Balance Check: Checking your balance is GET - you’re viewing information without withdrawing money. You can check your balance repeatedly without affecting the balance.
Code Example
// Simple GET request
GET /api/users/123 HTTP/1.1
Host: api.example.com
Accept: application/json
// GET with query parameters
GET /api/users?role=admin&status=active HTTP/1.1
Host: api.example.com
Accept: application/json
// Response
HTTP/1.1 200 OK
Content-Type: application/json
Cache-Control: max-age=300
ETag: "33a64df551425fcc55e4d42a148795d9"
{
"id": 123,
"name": "Alice",
"email": "[email protected]",
"role": "admin"
}
Diagram
sequenceDiagram participant Client participant Cache participant Server Client->>Cache: GET /api/users/123 Cache-->>Client: Cache miss Client->>Server: GET /api/users/123 Server->>Server: Read data (no modification) Server->>Client: 200 OK + Data Client->>Cache: Store in cache Note over Client,Server: Safe & Idempotent: no side effects
Security Notes
CRITICAL: GET is idempotent and should NEVER modify state. URL data is logged everywhere.
Data Leakage in URLs:
- Never put sensitive data in URLs: Passwords, tokens, PII are logged by servers, proxies, browsers, and CDNs
- URL logging: Logs in servers, application performance monitors, analytics, CDNs retain URLs
- Use POST instead: Send sensitive data in request body, not URL parameters
- Cache consideration: GET responses may be cached; don’t cache sensitive data
State Modification Security:
- GET must be idempotent: GET requests should NEVER modify state (no side effects)
- CSRF vulnerability: If GET modifies state, browser CSRF attacks can trigger it without user consent
- Use POST/PUT/DELETE: State-changing operations must use methods that require explicit intent
Input Validation:
- Validate query parameters: Sanitize all query string parameters to prevent injection attacks
- Prevent path traversal: Validate and restrict path-based parameters
- Bound result sets: Limit query results to prevent resource exhaustion
- Type validation: Validate parameter types before processing
Authentication & Access Control:
- Authenticate GET requests: Require authentication even for GET to control data access
- Rate limiting: Prevent scraping and enumeration attacks via aggressive rate limits
- Consistent authorization: Check permissions server-side for every GET request
Transport & Caching:
- HTTPS mandatory: Encrypt URL parameters in transit (URLs visible in transit without HTTPS)
- Cache headers: Don’t cache sensitive data; set Cache-Control: private, no-cache
- Redirect validation: Validate redirect destination URLs
Best Practices
- Use GET only for retrieving data, never for modifications
- Keep GET requests safe (no side effects) and idempotent
- Put parameters in query string, not body (some clients ignore body)
- Use appropriate status codes (200 OK, 404 Not Found, 304 Not Modified)
- Support caching with Cache-Control, ETag, Last-Modified headers
- Implement pagination for large collections
- Support filtering and sorting via query parameters
- Never include sensitive data in URLs
- Validate and sanitize all query parameters
- Return consistent response format (JSON, XML, etc.)
Common Mistakes
Using GET to modify data (breaks safe semantics), putting sensitive data in URLs, ignoring caching headers, returning 200 for not found (use 404), not supporting conditional requests (If-None-Match, If-Modified-Since), accepting request body in GET (many clients don’t send it), not validating query parameters, missing pagination for large results, poor error handling.