Spring Data JPA & REST API
Complete Reference Guide
Units III, IV & V
Comprehensive coverage of Spring Data JPA queries, Web Services, and REST API development
Table of Contents
Unit III: Spring Data JPA
Query Approaches in Spring Data JPA
Transaction Management for Updates
Custom Repository Implementation
Unit IV: Web Services
SOAP vs RESTful Web Services
Protocols and Message Formats
HTTP Methods and CRUD Operations
Service Oriented Architecture (SOA)
Statelessness in REST
Unit V: Spring REST
Components of Spring REST Service
Data Exchange with @RequestBody and ResponseEntity
Responsibilities of @RequestBody and ResponseEntity
Production Concerns and CORS
Unit III: Spring Data JPA
Question 1
Explain the different approaches to writing queries in Spring Data JPA. Contrast the usage of
Derived Query Methods naming convention, Query annotation, and Named Queries (NamedQuery
or XML configuration), highlighting when one approach is preferable over the others.
Spring Data JPA offers several methods for creating queries, each with benefits depending on the
complexity and reuse required:
1. Derived Query Methods:
This approach lets you write repository methods using a naming convention. Spring parses the method
name and generates the corresponding query.
interface UserRepository extends JpaRepository<User, Long> {
List<User> findByLastNameAndAge(String lastName, int age);
}
This generates a query like: SELECT u FROM User u WHERE [Link] = ?1 AND [Link] = ?2
When to use: For straightforward queries where the naming pattern suffices.
2. @Query Annotation:
For more complex queries, use the @Query annotation to specify JPQL or native SQL manually.
@Query("SELECT u FROM User u WHERE [Link] = :email")
User findByEmail(@Param("email") String email);
// Native query example
@Query(
value = "SELECT * FROM users WHERE status = ?1",
nativeQuery = true
)
List<User> findByStatus(String status);
When to use: Custom logic, multi-table joins, or database-specific features.
3. Named Queries:
Define reusable queries with the @NamedQuery annotation in entity classes or via XML.
@Entity
@NamedQuery(
name = "[Link]",
query = "SELECT u FROM User u WHERE [Link] = true"
)
class User {
// Entity fields...
}
// Repository interface
List<User> findByActive();
These named queries are great for reuse and separating query definition from Java logic.
Preference Guidelines:
Use derived queries for simplicity
Use @Query for flexibility
Use named queries for standardized reuse across your codebase
Question 2
Why is Spring Transaction management crucial for an Update Operation in Spring Data JPA, and
what problem does the Why Spring Transaction section primarily address?
Spring's transaction management ensures atomicity for database operations: either all work in a
transaction succeeds, or none of it does. This is particularly vital for update operations because:
If an update operation fails midway (e.g., due to a power outage or exception), the transaction
management will automatically roll back any partial changes, ensuring the database remains
consistent and free from corrupt or partial data.
Transactions also handle concurrency. If multiple users are trying to update the same data at once,
Spring's transaction boundaries help prevent conflicts or lost data.
Code Example:
@Transactional
public void updateUserAddress(Long userId, String newAddress) {
User user = [Link](userId).orElseThrow(...);
[Link](newAddress);
[Link](user);
}
Here, if anything fails during updateUserAddress, the database changes will be rolled back.
Problem Addressed: Data integrity and consistency during update operations.
Question 3
Briefly outline the steps and motivation for creating a Custom Repository Implementation when
the standard Spring Data JPA methods are insufficient.
Motivation:
The standard JPA methods (CRUD and basic query derivation) are sometimes too limited. For example,
you might need advanced business logic, integration with other data sources, or multi-step data
manipulation.
Steps for Custom Implementation:
1. Define a fragment interface for your desired custom methods:
public interface CustomUserRepository {
void customLogic(User user);
}
2. Implement the interface in a class with the postfix Impl:
public class CustomUserRepositoryImpl implements CustomUserRepository {
@Override
public void customLogic(User user) {
// Custom implementation
// Could use EntityManager or other beans
}
}
3. Extend your repository interface with the fragment interface:
public interface UserRepository
extends JpaRepository<User, Long>, CustomUserRepository {
}
4. Spring will detect and wire the custom implementation because of the naming convention.
Example Use Case:
Suppose you need a method to batch update users based on complex business rules that cannot be
expressed using derived queries or @Query. Here, you implement it in a separate custom repository
fragment.
Extra Note: You can inject beans or use JPA's EntityManager in your implementation, allowing
advanced interaction beyond basic CRUD.
Unit IV: Web Services
Question 1
Differentiate between the primary Types of Web Services. Provide a detailed comparison between
SOAP based Web Services and RESTful Web Services regarding their communication protocols,
message formats, dependence on WSDL, and overall coupling level.
The two primary types of web services are SOAP-based Web Services and RESTful Web Services,
each serving different needs in distributed systems:
SOAP-Based Web Services:
Protocol: SOAP is a protocol designed for exchanging structured information between computers
over a network. It commonly uses HTTP or SMTP but also supports FTP and others.
Message Formats: All SOAP messages are encoded in XML, regardless of the platform or
programming language.
Example SOAP request:
<soapenv:Envelope xmlns:soapenv="[Link]
<soapenv:Body>
<getNote>
<eventID>1000</eventID>
</getNote>
</soapenv:Body>
</soapenv:Envelope>
WSDL Dependence: SOAP services rely heavily on WSDL (Web Services Description Language) for
service contracts.
Coupling Level: The dependency on WSDL results in tight coupling—both the provider and
consumer must strictly adhere to the contract.
Integration Features: SOAP supports WS-Security, built-in error handling, and transactional
reliability.
RESTful Web Services:
Protocol: REST is an architectural style rather than a protocol. It uses standard HTTP for
communication.
Message Formats: RESTful services are flexible—they support JSON, XML, HTML, and plain text.
Example REST GET request & response:
GET /users/42
{
"id": 42,
"name": "Jane Smith"
}
WSDL Dependence: RESTful APIs do not use WSDL. Instead, they rely on documentation and
discoverability through hyperlinks (HATEOAS).
Coupling Level: RESTful services are loosely coupled—clients only need to know the base URL
and required data formats.
Comparison Table:
Criteria SOAP-Based Web Services RESTful Web Services
Protocol SOAP (over HTTP/SMTP/FTP) HTTP
Data Format XML JSON, XML, HTML, Text
Service Contract WSDL (required) Not required
Coupling Level Tight Loose
Error Handling XML Faults HTTP Status Codes
Security WS-Security, built-in Custom (OAuth, JWT, HTTPS)
Use Case Enterprise apps, complex Web/mobile/cloud, scalable
Performance Slower, heavy Lightweight, fast
Question 2
Differentiate between SOAP based Web Services and RESTful Web Services in terms of their use of
protocols and message formats.
SOAP-based Web Services:
Protocol Use: SOAP operates as its own protocol, encapsulating web service calls inside XML-based
envelopes and supporting multiple transport layers like HTTP and SMTP.
Message Format: Enforces a strict XML format for requests and responses.
Example:
<soapenv:Envelope xmlns:soapenv="[Link]
<soapenv:Header>
<Authentication>UserToken</Authentication>
</soapenv:Header>
<soapenv:Body>
<GetUser>
<UserID>101</UserID>
</GetUser>
</soapenv:Body>
</soapenv:Envelope>
RESTful Web Services:
Protocol Use: REST directly utilizes HTTP for all operations, mapping resources to URIs and CRUD
to HTTP verbs.
Message Format: Any format can be used, but JSON is default because it's lightweight and easy to
parse.
JSON Example:
{
"id": 101,
"name": "Jane Doe"
}
XML Example:
<user>
<id>101</id>
<name>Jane Doe</name>
</user>
Question 3
Focusing on RESTful Web Services, what is the role of HTTP? Explain how REST leverages
standard HTTP methods (GET, POST, PUT, DELETE) to implement the fundamental CRUD
operations, adhering to the principle of a Uniform Interface.
HTTP is the foundation of RESTful Web Services, providing a standardized way to interact with resources.
REST leverages HTTP methods to map CRUD operations as follows:
GET: Used to retrieve resource data.
Example: GET /users/40 returns user with ID 40.
POST: Used to create new resources.
Example: POST /users with { "name": "Jane" } creates a new user.
PUT: Used to update existing resources.
Example: PUT /users/40 with payload { "name": "Jane" } updates user 40.
DELETE: Used to remove resources.
Example: DELETE /users/40 removes user 40.
Uniform Interface Principle:
All RESTful endpoints follow predictable, standardized interactions; clients can expect consistent behavior
just by knowing the URI and method.
Status Codes:
HTTP status codes (e.g., 200 for success, 404 for not found, 201 for created, 500 for errors) communicate
operation status.
Spring Boot REST Controller Example:
@RestController
@RequestMapping("/users")
public class UserController {
@GetMapping("/{id}")
public User getUser(@PathVariable Long id) {
// Return user logic
}
@PostMapping
public User createUser(@RequestBody User user) {
// Create user logic
}
@PutMapping("/{id}")
public User updateUser(
@PathVariable Long id,
@RequestBody User user
) {
// Update user logic
}
@DeleteMapping("/{id}")
public void deleteUser(@PathVariable Long id) {
// Delete user logic
}
}
Benefits:
REST over HTTP enables statelessness, scalability, caching, layered architecture, and uniform
interaction patterns that are easily testable and maintainable.
Question 4
What is SOA - Service Oriented Architecture, and how did the rise of Web Services address the
need for better interoperability and loose coupling?
SOA (Service Oriented Architecture) is an approach to building software systems where discrete
components (services) are developed and deployed independently. Each service exposes a standardized
contract and is discoverable by clients.
Interoperability:
SOA enables disparate systems to communicate using open protocols (HTTP, XML, SOAP), regardless of
their programming language, OS, or internal design. This reduces integration challenges and allows
systems from different vendors to work together.
Loose Coupling:
Services are independent—changing the internal logic of a service does not impact client code, as long as
the contract remains the same. This boosts flexibility and ease of maintenance.
Service Registry:
Services can be published to directories (such as UDDI) and found by consumers, supporting dynamic and
scalable integrations.
SOA Principles:
Standardized Service Contract: Clearly defined interfaces (often WSDL for SOAP, OpenAPI for
REST)
Service Reusability: Services are generic and reusable across multiple applications
Service Abstraction: Internal implementation details are hidden from consumers
Service Autonomy: Services control their own logic and resources
Service Statelessness: Ideally, services do not retain state from request to request
Impact of Web Services:
The rise of web services enabled organizations to rapidly integrate and automate processes, share data
across platforms, streamline workflows, and easily adapt to new business requirements by reusing and
composing services.
Example:
In banking, authentication, payments, and account queries can each be individual services. Web apps,
mobile apps, and third-party aggregators can reuse these services in different contexts without
knowledge of underlying implementations.
Question 5
Analyze the concept of 'State' in Web Services. Explain why RESTful Web Services are generally
preferred to be stateless (as per the REST constraints), and what benefits this statelessness
provides.
State refers to information about previous interactions a server retains to contextualize new requests.
RESTful Web Services are designed to be stateless, meaning:
Each request from client to server must contain all the information needed to process the request.
The server does not store anything about the client's session between requests.
Why prefer statelessness?
Scalability: With no session management overhead, REST servers can easily distribute requests
across multiple nodes. Any server in a cluster can handle any request, eliminating sticky sessions.
Reliability and Flexibility: Stateless design simplifies failover and disaster recovery—no need to
sync session data.
Caching: Requests and responses can be cached more efficiently, since no session dependencies exist.
Security: Each interaction is self-contained, reducing risks related to session hijacking.
Example:
A user adds items to a shopping cart using a REST API. The cart's state is stored either client-side
(browser) or in a back-end database. Every subsequent request includes the cart ID or user token to
identify the contents—no memory of the cart is kept in the API server's memory.
Benefits:
Easier scaling (horizontal/vertical)
Simplified infrastructure (no session replication required)
Improved performance with stateless load balancing and caching
More resilient systems (stateless RESTful services are easier to restart and recover)
Unit V: Spring REST
Question 1
Explain the fundamental components of a Spring REST service. Describe the role of the Spring
REST Controller and how it maps incoming HTTP requests to specific handler methods using
annotations like @RequestMapping or its specialized variants.
A typical Spring REST service is built using the core parts of the Spring MVC architecture, adapted for
RESTful data exchange:
DispatcherServlet:
This is the front controller that intercepts all HTTP requests to the application. It is responsible for
handing off requests to the relevant handler based on URL and HTTP method.
Handler Mapping:
This component maps request URLs to controller classes and methods. Spring uses this to figure out which
controller should process each request.
Spring REST Controller:
Classes annotated with @RestController are responsible for receiving and processing RESTful requests. In
REST mode, these controllers return data (objects, usually in JSON format) rather than view pages. The
@RestController annotation combines @Controller and @ResponseBody, meaning every method in a REST
controller automatically sends its return value as a HTTP response body.
Example:
@RestController
@RequestMapping("/customers")
public class CustomerController {
@GetMapping
public List<CustomerDTO> fetchCustomer() {
return [Link]();
}
}
Request Mapping with Annotations:
You use method-level annotations to connect HTTP requests to handler methods:
@RequestMapping: Generic mapping (can specify HTTP method, path, etc.)
Specialized forms:
@GetMapping, @PostMapping, @PutMapping, @DeleteMapping
These annotations allow precise control over which HTTP actions trigger which method.
Example mapping GET request to handler method:
@GetMapping(
value = "/{id}",
produces = "application/json"
)
public CustomerDTO getCustomer(@PathVariable Long id) {
return [Link](id);
}
Spring Boot simplifies setup, auto-configures much of the REST stack, and supports annotation-based
programming for rapid development.
Question 2
How does a Spring REST service handle data exchange in the request and response bodies? Detail
the purpose and usage of @RequestBody for deserializing incoming payload (e.g., JSON) into Java
objects, and ResponseEntity for controlling the HTTP status code and response body.
REST services must translate between HTTP payloads (typically JSON/XML) and Java objects. Spring
makes this easy with two key tools:
@RequestBody Annotation:
When an HTTP POST or PUT request is made, data (such as a user or order) is sent in the request body,
usually in JSON.
The @RequestBody annotation tells Spring to deserialize this incoming payload into the target Java
object, using Jackson (for JSON) under the hood.
Example:
@PostMapping(consumes = "application/json")
public ResponseEntity<String> createCustomer(
@RequestBody CustomerDTO customerDTO
) {
[Link](customerDTO);
return [Link]("Customer created");
}
Here, incoming JSON is converted to a CustomerDTO object.
ResponseEntity Class:
Used for customized control over both response data and metadata (status codes, headers, etc.).
Example:
@PostMapping("/customers")
public ResponseEntity<String> createCustomer(
@RequestBody CustomerDTO customerDTO
) {
String response = [Link](customerDTO);
HttpHeaders headers = new HttpHeaders();
[Link]("Custom-Header", "Value1");
return new ResponseEntity<>(response, headers, [Link]);
}
This allows the response to include a status ("201 Created"), custom headers, and a response body.
The combination of @RequestBody and ResponseEntity ensures that data is reliably exchanged and well-
formed between clients and servers, with clear status feedback.
Question 3
In the context of creating a REST endpoint, what are the primary responsibilities of
@RequestBody and ResponseEntity?
@RequestBody:
Converts HTTP request payload (JSON/XML) into a Java object.
Triggers automatic validation when used in conjunction with annotations like @Valid (for DTOs with
fields such as @NotNull, @Email).
Allows rich Java objects to be directly passed to service methods, streamlining business logic.
ResponseEntity:
Encapsulates the entire HTTP response, not just the body.
Lets you set HTTP status codes (e.g., 200 OK, 201 Created, 400 Bad Request).
Lets you attach custom headers for metadata or control.
Allows you to return any object as a response body, which Spring serializes as JSON or XML.
Used for returning error messages, success notices, and appropriate status responses based on
business logic or validation results.
Example of both in action:
@PostMapping(consumes = "application/json")
public ResponseEntity<?> createCustomer(
@Valid @RequestBody CustomerDTO customerDTO,
Errors errors
) {
if ([Link]()) {
String errorMsg = [Link]().stream()
.map(ObjectError::getDefaultMessage)
.collect([Link](", "));
return [Link]().body(errorMsg);
}
[Link](customerDTO);
return ResponseEntity
.status([Link])
.body("Customer created successfully");
}
Here, payload is deserialized, validated, and a tailor-made response is sent to the client.
Question 4
Address the key operational and security concerns for a production REST endpoint. Define CORS
(Cross-Origin Resource Sharing) and explain why Enabling CORS in Spring REST is necessary.
Modern REST APIs face several real-world operational and security issues:
Authentication & Authorization:
Use Spring Security for login credentials, user roles, OAuth2, JWT, etc., to protect sensitive endpoints.
Production APIs should never be left open to the public.
Data Validation:
@Valid annotation and Bean Validation API (@NotNull, @Email) to ensure incoming data is well-formed and
safe.
Exception Handling:
Use @RestControllerAdvice and @ExceptionHandler to provide meaningful error messages and avoid exposing
stack traces (which are security risks).
Versioning:
URI or header-based versioning to maintain backward compatibility during API upgrades.
CORS (Cross-Origin Resource Sharing):
Definition: CORS is a security feature implemented by browsers that blocks AJAX requests from one
domain to another unless explicitly allowed by the server.
Why Necessary: If your frontend (say, an Angular app on [Link]) needs to access your Spring
REST API running on [Link], browsers will block requests without CORS.
How to Enable:
Annotation-based per controller/method:
@CrossOrigin(origins = "[Link]
@GetMapping("/customers")
public List<Customer> getCustomers() {
// Return customers
}
Globally (via WebMvcConfigurer):
@SpringBootApplication
public class App implements WebMvcConfigurer {
@Override
public void addCorsMappings(CorsRegistry registry) {
[Link]("/**")
.allowedOrigins("*")
.allowedMethods("GET", "POST", "PUT", "DELETE");
}
}
Benefits:
Enables safe, controlled access to REST endpoints from multiple domains.
Prevents browser security errors for legitimate cross-domain use cases (e.g., JavaScript clients,
mobile apps).
Spring Boot makes it easy to configure all these concerns, allowing you to focus on business logic
while maintaining robust, secure REST APIs.