HTTP Status Codes & Methods in REST API with Spring Boot & Spring MVC

1. Introduction

In RESTful services, HTTP status codes and methods play a crucial role in determining the success or failure of requests. Understanding how to use these correctly helps in building robust APIs. In this post, we’ll look at common HTTP status codes (200, 400, 401) and HTTP methods (GET, POST, PUT, DELETE) in the context of Spring Boot and Spring MVC, with real-time use cases for employee management, gaming, teaching, and food order payments.
 

2. HTTP Status Codes

2.1. HTTP 200 – OK

The HTTP 200 status code indicates a successful request. It’s the standard response for successful GET, POST, PUT, and DELETE requests.

Use Case: Employee Management

In an employee management system, after adding or updating an employee, a response with a 200 OK status is sent to confirm that the request was successfully processed.

Sample Code

2.2. HTTP 400 – Bad Request

The HTTP 400 status code indicates that the server could not process the request due to client-side errors, such as invalid data or missing parameters.

Use Case: Gaming

In a gaming API, if a player sends an invalid move (e.g., a non-existent character ID), the server responds with a 400 Bad Request status.

Sample Code

2.3. HTTP 401 – Unauthorized

HTTP 401 status code means the client is unauthorized to access the requested resource, typically due to missing or invalid authentication.

Use Case: Teaching Platform

In a teaching platform API, a teacher or student attempting to access resources without being logged in would get a 401 Unauthorized status.

Sample Code

3. HTTP Methods

3.1. GET

The GET method retrieves data from the server.

Use Case: Food Order System

In a food order system, retrieving a list of menu items using a GET request.

Sample Code

3.2. POST

The POST method is used to send data to the server, such as creating a new record.

Use Case: Employee Management

Creating a new employee record.

Sample Code

3.3. PUT

The PUT method is used to update an existing resource.

Use Case: Gaming

Updating a player’s status in a game.

Sample Code

3.4. DELETE

The DELETE method is used to remove a resource from the server.

Use Case: Food Order System

Deleting an item from a customer’s food order.

Sample Code

5. HTTP 201 – Created

The HTTP 201 status code indicates that a request has been successfully processed and resulted in the creation of a new resource.

Use Case: Employee Management

When an employee is successfully created, return a 201 Created status.

Sample Code

6. HTTP 202 – Accepted

The HTTP 202 status code indicates that the request has been accepted for processing, but the processing has not been completed.

Use Case: Gaming

When a game action is initiated, but not completed yet (e.g., a server-side action like saving game progress), return HTTP 202.

Sample Code

7.HTTP 203 – Non-Authoritative Information

The HTTP 203 status code indicates that the response metadata is not from the origin server but from a local or third-party copy.

Use Case: Teaching Platform

In an online teaching platform, if course data is fetched from a cached version, this status code may be used.

Sample Code

8.HTTP 204 – No Content

The HTTP 204 status code indicates that the request has been successfully processed, but there is no content to return.

Use Case: Food Order System

When a food order is successfully updated (e.g., a customer changes their delivery address), return HTTP 204 No Content.

Sample Code

9. HTTP 301 – Moved Permanently

The HTTP 301 status code indicates that the resource requested has been permanently moved to a new location.

Use Case: Food Order System

If a food delivery address API has moved to a new endpoint, this status code is returned.

Sample Code

10.HTTP 302 – Found (Temporary Redirect)

The HTTP 302 status code indicates that the resource is temporarily located at a different URI.

Use Case: Gaming

If a player's request is temporarily redirected to a new game server for load balancing.

Sample Code

11.HTTP 400 – Bad Request

This indicates that the request could not be understood or was missing required parameters.

Use Case: Food Order System

If a customer places an incomplete order (missing item details), return HTTP 400.

Sample Code

12. HTTP 401 – Unauthorized

This status indicates that the request lacks valid authentication credentials.

Use Case: Teaching Platform

A student or teacher attempting to access course content without being logged in should receive this status.

Sample Code

13. HTTP 402 – Payment Required

This status code is not widely used, but it could indicate that payment is required to proceed with the request.

Use Case: Food Order Payment

In a food ordering system, the user is asked to pay before placing an order.

Sample Code

14. HTTP 403 – Forbidden

This status indicates that the server understands the request but refuses to authorize it.

Use Case: Teaching Platform

If a user tries to access restricted courses they don't have permission for, return HTTP 403.

Sample Code

15. HTTP 404 – Not Found

This status indicates that the requested resource could not be found.

Use Case: Employee Management

When an employee with a specific ID does not exist in the system.

Sample Code

16. HTTP 500 – Internal Server Error

This indicates that the server encountered an unexpected condition that prevented it from fulfilling the request.

Use Case: Gaming

When there’s an unexpected error in the game server (e.g., database failure).

Sample Code

17. HTTP 502 – Bad Gateway

This status code indicates that the server received an invalid response from the upstream server.

Use Case: Food Order Payment

If a food payment gateway returns an error, a 502 Bad Gateway status could be returned.

Sample Code

Use Case Examples:

1. GET:
   • Retrieving a list of products from an e-commerce website.
   • Fetching weather data from an API.
   • Getting employee details in an HR system.
2. POST:
   • Creating a new blog post.
   • Registering a new user in a system.
   • Submitting an order in an online store.
3. PUT:
   • Updating an existing user's profile with new information (like changing the username).
   • Replacing a product's details in an e-commerce system (e.g., replacing the entire product record).
   • Updating employee contact information.
4. DELETE:
   • Deleting a specific product from the product catalog.
   • Removing a comment from a blog post.
   • Deleting an item from the shopping cart.
5. PATCH:
   • Updating the address field of a user's profile without changing other details.
   • Modifying only the salary field in an employee's record.
   • Partially updating a product's description without replacing the entire product.

Detailed Explanation of Each Scope:

1. Singleton Scope:
   • Description: A single instance of the bean is created for the entire Spring container. Every request for the bean returns the same instance.
   • When to Use: Ideal for stateless, shared services or components like logging, caching, or configuration classes.
   • Example: A singleton service to handle email notifications, where one instance can handle all email requests.
2. Prototype Scope:
   • Description: A new instance of the bean is created every time it is requested from the Spring container.
   • When to Use: When each request needs a fresh, isolated instance of the bean. Common in scenarios like processing a user request where the state is not shared.
   • Example: A form or a complex object that should not maintain any state across requests.
3. Session Scope:
   • Description: The bean is created once per HTTP session and exists for the duration of the session.
   • When to Use: Used to store session-specific data such as user preferences, a shopping cart, or a user profile that persists during a session.
   • Example: Storing information like a user’s shopping cart across multiple requests during a session.
4. Application Scope:
   • Description: A single instance of the bean is shared across the entire web application.
   • When to Use: For beans that need to be shared globally across all users and HTTP sessions.
   • Example: A configuration class holding application-wide settings or constants, such as the application's version or default timezone.
5. Request Scope:
   • Description: A new bean is created for each HTTP request. It is destroyed after the request is processed.
   • When to Use: Useful for beans that only need to exist for the duration of a request, like form objects or request-specific processing.
   • Example: A form handler bean that processes data only for the duration of one HTTP request.
6. Global Session Scope:
   • Description: A special scope used in portlet environments. A session that spans across multiple applications within a portal.
   • When to Use: Applicable only in a portlet-based environment, not typical for standard Spring Boot applications.
   • Example: Sharing session information between different portlets within the same portal.

Usage in Spring MVC & Spring Boot:

• Session Scope in Spring Boot/Spring MVC is typically used for data that should persist during the lifecycle of a user's session. For example, a user’s authentication information or a shopping cart in an e-commerce application.
• Singleton Scope is most commonly used for services that are stateless or need to share data across requests, such as logging services, caching services, or repository classes.
• Prototype Scope is useful for cases where a new instance of a class should be created on every request, such as for forms or request-specific data processing.
• Request Scope is typically used for handling form data that should only persist for a single HTTP request and should not be shared between requests.

Examples: