ReviseAlgo Logo

Web Development Basics

REST APIs

Representational State Transfer (REST) architecture constraints, URL design, HTTP methods, and API best practices.

Interview: System design and API architecture. Frequently evaluated for resource routing, status codes, pagination, and API design standards.

Last Updated: June 12, 2026 7 min read

REST (Representational State Transfer) is an architectural style for designing networked applications. It utilizes stateless, client-server communications, mapping resource locations directly to clean URLs and standard HTTP methods.

REST Constraints

  • Client-Server separation: Clients handle UI, servers handle data storage.
  • Statelessness: Every request from a client must contain all information needed to process it. The server stores no session context.
  • Cacheability: Responses must define themselves as cacheable or not to improve network efficiency.
  • Uniform Interface: Resource identification (URI), resource representation (JSON/XML), self-descriptive messages, and HATEOAS.

URL Design Guidelines

URLs should represent nouns (resources) rather than verbs (actions). Action behaviors are mapped to HTTP methods.

  • GET /users — List all users (plural nouns)
  • GET /users/123 — Retrieve details of user 123
  • POST /users — Create a new user
  • PUT /users/123 — Replace details of user 123
  • DELETE /users/123 — Delete user 123

Use Cases

Public API design — Creating clean, predictable endpoint architectures consumed by external developer communities.

Client-Server Decoupling — Building web services where frontend applications (React, iOS apps) consume a unified data endpoint.

Third-party Webhooks — Sending event webhooks in standard RESTful structures.

Common Mistakes

Using verbs in URLs — Designing endpoints like `POST /createUser` or `GET /get_all_users` instead of `POST /users` and `GET /users`.

Ignoring HTTP status codes — Returning `200 OK` with error payloads (e.g. `{"error": "not found"}`) instead of proper `404` status codes.

Lack of versioning — Exposing API endpoints without versions (like `/api/users` instead of `/api/v1/users`), causing breaking changes for clients on modifications.