Spring Web Interview Questions and Answers

•  What are REST services ?

REST (Representational State Transfer) is an architectural style for building web services that interact using standard HTTP methods (GET, POST, PUT, DELETE, etc.). It relies on stateless communication and uses resource-based URIs (Uniform Resource Identifiers) for addressing.

Here are some key features of RESTful services:

1. Stateless: Each request from the client to the server must contain all the information needed to understand the request. The server does not store any information about previous requests (no session state).
2. Uses HTTP methods: RESTful services primarily use standard HTTP methods like:
   • GET: To retrieve data from the server.
   • POST: To send data to the server (e.g., for creating a new resource).
   • PUT: To update a resource on the server.
   • DELETE: To delete a resource from the server.
3. Resource-based: In REST, resources (such as data or services) are represented as URLs (Uniform Resource Locators). Each resource is identified by a unique URI (Uniform Resource Identifier).
4. Stateless Communication: Each interaction between the client and server is independent. The client needs to provide all necessary information with every request, including authentication if required.
5. Use of standard data formats: REST services typically use standard data formats for communication, such as JSON (JavaScript Object Notation) or XML (eXtensible Markup Language), but JSON is more common due to its simplicity.
6. Cacheable: Responses from the server can be marked as cacheable or non-cacheable to improve performance.
7. Uniform Interface: RESTful services emphasize a consistent and standardized interface for interacting with resources, which simplifies the architecture and promotes loose coupling between clients and servers.

• Difference between @PathVariable and @RequestParam annotation.

@PathVariable Annotation:

1. Purpose: It is used to bind a variable in the URI (path) of the request to a method parameter.
2. Use Case: Typically used when dealing with RESTful APIs where the values are part of the URL itself.
3. URL Example: It's commonly used when you have a RESTful URL structure where specific parameters are embedded directly in the path.

Example:

@GetMapping("/users/{id}")
public String getUserById(@PathVariable("id") int userId) {
    
    return "User ID: " + userId;

URL: /users/123
Result: The id parameter is extracted from the URL (123) and passed to the method as userId.

Common Use: Path variables are ideal when you want to represent hierarchical or resource-based URLs, such as /products/{productId} or /users/{userId}.

---

@RequestParam Annotation:

1. Purpose: It is used to extract query parameters from the query string (the part of the URL after the ?).
2. Use Case: Typically used to capture values passed as query parameters in the URL, like ?key=value.
3. URL Example: It's commonly used when dealing with form submissions, search queries, or optional parameters that appear in the query string.

Example:

@GetMapping("/search")
public String searchUser(@RequestParam("name") String userName) {
    return "Searching for user: " + userName;
}

URL: /search?name=John
Result: The name query parameter (John) is extracted and passed to the method as userName.
Common Use: @RequestParam is often used for filtering, sorting, pagination, or other optional parameters that don’t directly represent a resource.

• Difference between @Controller and @RestController annotation.

Feature	@Controller	@RestController
Purpose	Used for traditional web apps that return views (HTML, JSP, etc.)	Used for RESTful APIs that return data (JSON, XML)
View Resolution	Returns a view name (resolved by a view resolver)	Does not return a view; returns data directly
Automatic @ResponseBody	Does not automatically add @ResponseBody (returns a view)	Automatically applies @ResponseBody to all methods, so returns data (JSON, XML, etc.)
Common Use Case	Traditional MVC web applications (server-rendered HTML pages)	REST APIs (client-side apps, mobile apps, etc.)
Return Type	View names (like String or ModelAndView)	Data objects (such as User objects, automatically converted to JSON)

• Can we use @Component annotation in Service class ?

Yes, you can use the @Component annotation in a service class, but it is generally not recommended to do so because @Component annotation is a generic stereotype annotation used to define a Spring managed bean (i.e., a component) in the Spring context whereas @Service annotation is a more specific specialization of @Component and is used to indicate that a class is a service.     

• How can you create REST services without using Spring ?

While Spring is a very popular and powerful framework for building REST services, there are        multiple alternatives in Java to build REST APIs without using Spring, depending on your needs:

1. JAX-RS for a more standardized approach (e.g., Jersey).
2. HttpServlet or HttpServer for a more manual, low-level approach.
3. Vert.x for reactive and highly scalable applications.
4. MicroProfile for microservices-based architectures.

• What is the difference between PUT and PATCH

PUT: Replaces the entire resource with the new data
PATCH: Updates only the specific fields of a resource.   

• What are some common HTTP status codes used in REST APIs and their meanings?

200 OK: The request was successful.
201 Created: A new resource was created.
400 Bad Request: The server could not understand the request due to invalid syntax.
401 Unauthorized: Authentication is required and has failed or not been provided.
403 Forbidden: The server understands the request but refuses to authorize it.
404 Not Found: The requested resource could not be found.
500 Internal Server Error: A generic error message for an unexpected server issue.
503 Service Unavailable: The server is temporarily unavailable (e.g., overloaded or under                 maintenance).

• What is idempotence in the context of RESTful APIs?

Idempotence means that performing the same operation multiple times will produce the same result, regardless of how many times the request is made. In other words, a request can be repeated without causing unintended side effects or different outcomes.

• Can you give an example of an idempotent HTTP method?

The PUT method is idempotent .For example, if you send a PUT request to update a resource, even if    you send the same PUT request multiple times with the same data, the result will always be the same i.e., the resource is updated to the same state, and no additional changes occur

• Which HTTP methods are typically idempotent in RESTful APIs?

GET: Fetching a resource is idempotent because retrieving the same resource multiple times doesn’t alter the resource itself

PUT: Updating a resource with the same data multiple times will always result in the same resource state.

DELETE: Deleting a resource repeatedly will not change the state after the first successful deletion (i.e., if the resource is already deleted, repeating the delete operation will have no effect).

• Which HTTP methods are not idempotent, and why?

POST: Typically used to create a new resource or perform actions that might have side effects. If you send the same POST request multiple times, it may create duplicate resources or cause other unintended side effects.

PATCH (in some cases): If the patch operation changes part of a resource's state based on its current state, then performing the same operation multiple times may yield different results (depending on the implementation).