REST API Essentials: Core Concepts and Practical Applications

Tahajjat TuhinTahajjat Tuhin
8 min read

In this article, we explore REST API Essentials: Core Concepts and Practical Applications — a comprehensive guide designed for beginner to intermediate developers. Whether you're just starting with RESTful APIs or aiming to deepen your understanding, this article covers the key principles of REST architecture, foundational concepts, and real-world implementation using Spring Boot.

To make it practical, we’ll build a Task Management API that demonstrates best practices, including pagination and search features — everything you need to start building robust REST APIs with confidence.

What You’ll Learn in This Article

  • Understanding REST APIs

  • REST Architectural Principles

  • Core REST Concepts: Resources, Sub-resources, and URIs

  • HTTP Methods: GET, POST, PUT, DELETE

  • HTTP Status Codes Explained

  • Real-world Implementation


Understanding REST APIs

REST (Representational State Transfer) is an architectural style used for building scalable and maintainable web services. It utilizes standard HTTP protocols to facilitate communication between a client—such as a ReactJS frontend/mobile apps—and a server—like a Spring Boot backend.

REST is not a protocol or a standard, it is an architectural style. During the development phase, API developers can implement REST in a variety of ways.

REST APIs are stateless, meaning each request from the client must contain all the information the server needs to process it. This makes REST APIs highly scalable and suitable for modern web applications. They return data in commonly used formats like JSON or XML, making them easy to work with across different platforms.

REST APIs allow clients to perform operations on resources (e.g., tasks, users, or products) using standard HTTP methods. Each resource is identified by a unique URI (Uniform Resource Identifier), and the API returns data in a format like JSON or XML.

A Web API (or Web Service) conforming to the REST architectural style is called a REST API (or RESTful API).

Key Characteristics of REST APIs:

  • Stateless: Each request contains all the information needed to process it.

  • Client-Server: Separates the client (UI) from the server (data storage and logic).

  • Cacheable: Responses can be cached to improve performance.

  • Layered System: The architecture can include intermediaries (e.g., load balancers).

  • Uniform Interface: Standardized methods and conventions for interaction.


REST Architectural Principles.

REST is built on a set of architectural constraints, often referred to as RESTful principles, proposed by Roy Fielding. These principles ensure scalability, simplicity, and interoperability:

  1. Statelessness: Each request from the client to the server must contain all necessary information. The server does not store client state between requests.

  2. Client-Server Separation: The client handles the user interface, while the server manages data and business logic. This separation improves maintainability and scalability.

  3. Cacheability: Responses indicate whether they can be cached, reducing server load and improving performance.

  4. Layered System: The architecture can include layers (e.g., gateways, proxies) without the client knowing the underlying complexity.

  5. Uniform Interface: REST APIs use standardized conventions, including:

  • Resource identification via URIs.

  • Manipulation of resources through standard HTTP methods.

  • Self-descriptive messages (e.g., including metadata in headers).

  • Hypermedia (HATEOAS), where responses include links to related resources.


Core REST Concepts: Resources, Sub-resources, and URIs

Understanding how REST APIs structure and access data is fundamental to building scalable and intuitive web services. At the heart of REST are resources, their relationships, and how they are accessed via URIs.

Resources

A resource is the core entity in a REST API, representing a specific piece of data (e.g., a task, user, or order). Each resource is identified by a unique URI.

Example:
A specific task can be accessed via the URI:
GET /tasks/123
Here, 123 is the unique identifier of the task.

Sub-resources

Sub-resources represent related entities under a parent resource. For example, a task might have comments as sub-resources, accessible via /tasks/123/comments.

A Sub-resource is a resource that exists in the context of another resource. This reflects a hierarchical relationship, such as comments belonging to a task.

Example:
To access the comments of a task with ID 123, you might use:
GET /tasks/123/comments

This clearly indicates that the comments are tightly coupled to the parent task.

URIs(Uniform Resource Identifiers)

URIs are the path-based addresses through which clients access and interact with resources. Following REST best practices ensures clean, predictable, and scalable API endpoints.

  • Use Nouns, Not Verbs - Resources should be named using nouns. Use HTTP methods to define the action( e.g., /tasks instead of /getTasks).

  • Use Plural Forms - Use plural resource names for collections( e.g., /users, /products).

  • Hierarchical Sub-resources - Reflect relationships via URI nesting ( e.g., /tasks/123/comments)

  • Use Query Parameters for Filtering, Sorting, or Pagination - Don’t overload path segments( e.g., /tasks?page=2&size=10&status=done).

  • Avoid File Extensions - Let content negotiation determine format(e.g.,/tasks instead of /tasks.json).


HTTP Methods: GET, POST, PUT, DELETE

RESTful APIs leverage standard HTTP methods to perform CRUD operations — Create, Read, Update, and Delete — on resources.

1. GET – Retrieve Resource(s). Used to fetch a single resource or a collection. It is safe and idempotent, meaning it doesn’t change the server state and returns the same result if repeated.

Examples:
GET /tasks → Retrieve all tasks
GET /tasks/123 → Retrieve the task with ID 123

2. POST – Create a New Resource. Used to create a new resource. Unlike PUT, POST is not idempotent — calling it multiple times may create duplicate entries.

Example:
POST /tasks
Request Body:
{
  "title": "Writing REST API Essentials LinkedIn article.",
  "created_at": "2025-06-23"
}
Response:
{
  "id": 123,
  "title": "Writing REST API Essentials LinkedIn article.",
  "created_at": "2025-06-23",
  "created_by": "Tahajjat"
  "updated_at": "2025-06-23",
  "status": "pending"
}

3. PUT – Update or Replace a Resource. Used to update an existing resource or create it if it doesn't exist. It is idempotent — multiple identical requests result in the same effect.

Example:
PUT /tasks/123
Request Body:
{
  "title": "Writing REST API Essentials LinkedIn article for beginner to intermediate learners.",
  "updated_at": "2025-06-23"
}
Response:
{
  "id": 123,
  "title": "Writing REST API Essentials LinkedIn article for beginner to intermediate learners.",
  "created_at": "2025-06-23",
  "created_by": "Tahajjat"
  "updated_at": "2025-06-25",
  "status": "pending"
}

4. DELETE – Remove a Resource. Used to delete a resource by ID. This method is idempotent — deleting the same resource multiple times has the same outcome.

Example:
DELETE /tasks/123 → Deletes task with ID 123

Best Practices for Using HTTP Methods:

  • Use POST strictly for creating resources.

  • Use PUT for full updates or upserts (create-if-not-exist).

  • Ensure idempotency for PUT and DELETE (repeating the request produces the same result).

  • Avoid using non-standard methods(e.g., sending updates with GET or creations with PUT) or overloading a single method for multiple purposes.

  • Follow URI naming conventions (e.g., plural nouns: /tasks, /users).


HTTP Status Codes Explained

HTTP status codes communicate the result of a client’s request to the server. Here are the most commonly used codes in REST APIs:

2xx - Success

  • 200 OK: Request succeeded (e.g., successful GET or PUT).

  • 201 Created: Resource created successfully (e.g., after POST).

  • 204 No Content: Request succeeded, no content to return (e.g., after DELETE).

3xx – Redirection

  • 301 Moved Permanently – The resource has been permanently moved to a new URL.

  • 304 Not Modified – The resource has not changed since the last request (used with caching).

4xx – Client Errors

  • 400 Bad Request – The request is malformed or has invalid parameters.

  • 401 Unauthorized – Authentication is required but not provided or is invalid.

  • 403 Forbidden – The client is authenticated but does not have permission to access the resource.

  • 404 Not Found – The requested resource could not be found.

5xx – Server Errors

  • 500 Internal Server Error – A generic error occurred on the server.

  • 503 Service Unavailable – The server is temporarily unable to handle the request (e.g., maintenance or overload).

Best Practice: Always return the appropriate status code along with a clear and informative error message, especially for 4xx and 5xx responses, to help clients understand and handle issues effectively.


Best Practices for REST APIs

  1. Use Meaningful URIs: Follow a clear, hierarchical structure (e.g., /tasks/{id}/comments).

  2. Return Appropriate Status Codes: Use 201 for creation, 204 for deletion, etc.

  3. Implement Pagination: Use query parameters like page and size for large datasets.

  4. Support Filtering and Searching: Allow clients to filter results (e.g., search=tutorial).

  5. Use JSON for Responses: JSON is lightweight and widely supported.

  6. Handle Errors Gracefully: Return meaningful error messages with 4xx/5xx codes.

  7. Secure Your API: Use HTTPS, authentication (e.g., JWT), and input validation.

  8. Version Your API: Use URI versioning (e.g., /v1/tasks) or header-based versioning.

  9. Document Your API: Use tools like Swagger/OpenAPI to generate documentation.

  10. Follow HATEOAS (Optional): Include links to related resources in responses for discoverability.


Conclusion

REST APIs are the backbone of modern web applications, enabling seamless communication between clients and servers. By understanding REST principles, HTTP methods, status codes, and best practices, you can design robust and scalable APIs. The Spring Boot example above demonstrates how to implement a Task Management API with pagination and search, following RESTful conventions.

In the next article of our Spring Boot & ReactJS Tutorial Series, we’ll explore Spring Boot Fundamentals: Building Your First REST API. Stay tuned, and feel free to share your thoughts or questions in the comments!

Happy coding! 🚀

0
Subscribe to my newsletter

Read articles from Tahajjat Tuhin directly inside your inbox. Subscribe to the newsletter, and don't miss out.

Written by

Tahajjat Tuhin
Tahajjat Tuhin