Understanding HTTP Status Codes in REST APIs with Java and Spring Boot

Day 24. My API was fast. Until it wasn't. I had this: return ResponseEntity.ok(userRepository.findAll()); 10 users in development. Works instantly. Feels perfect. Then production happened: → 50,000 users in the database → One API call loads everything → Response time: 40ms → 8 seconds → Memory spikes → API crashes That's not a performance issue. That's a design mistake. And it was there from day one. I just couldn't see it yet. That's when it clicked: Your API should never decide how much data to return. The client should. So I added pagination. (see implementation below 👇) What changed: → Performance — stable response time → Scalability — works at 100 or 100,000 rows → Stability — no memory spikes The hard truth: → findAll() works in tutorials → It breaks in production → Pagination is not an optimization — it's a requirement Fetching data is easy. Controlling how much you fetch is what makes your API scalable. Are you still using findAll() in production? 👇 Drop it below #SpringBoot #Java #BackendDevelopment #Performance #JavaDeveloper

APIs started making sense to me when I stopped memorizing… and started understanding the flow 👇 At a basic level, an API is just a way for systems to communicate. But what actually happens when you hit an API? Let’s break it down: 1️⃣ Client sends a request Example: GET /users/1 2️⃣ Request reaches the server → Routed to the correct controller 3️⃣ Business logic runs → Service layer processes the request 4️⃣ Database interaction → Fetch / update data 5️⃣ Response is returned → Usually JSON So the real flow is: 👉 Client → Controller → Service → Database → Response What helped me most was understanding this: • APIs are not just endpoints • They are structured layers working together Also, things started clicking when I focused on: • HTTP methods (GET, POST, PUT, DELETE) • Status codes (200, 404, 500) • Request & response structure Still learning, but understanding this flow made backend development much clearer. If you're learning APIs, focus on the flow — not just the syntax. #BackendDevelopment #APIs #Java #SpringBoot #WebDevelopment #Developers #LearningInPublic

Clean REST API in Spring Boot (Best Practice) 🚀 Here’s a simple structure you should follow 👇 📁 Controller - Handles HTTP requests 📁 Service - Business logic 📁 Repository - Database interaction Example 👇 @RestController @RequestMapping("/users") public class UserController { @Autowired private UserService userService; @GetMapping("/{id}") public User getUser(@PathVariable Long id) { return userService.getUserById(id); } } 💡 Why this matters: ✔ Clean code ✔ Easy testing ✔ Better scalability ⚠️ Avoid: Putting everything inside controller ❌ Structure matters more than code 🔥 Follow for more practical backend tips 🚀 #SpringBoot #Java #CleanArchitecture #Backend

#Post6 In the previous posts, we built basic REST APIs step by step. But what happens when something goes wrong? 🤔 Example: User not found Invalid input Server error 👉 By default, Spring Boot returns a generic error response. But in real applications, we need proper and meaningful error handling. That’s where Exception Handling comes in 🔥 Instead of handling exceptions in every method, Spring provides a better approach using @ControllerAdvice 👉 It allows us to handle exceptions globally Example: @ControllerAdvice public class GlobalExceptionHandler { @ExceptionHandler(Exception.class) public String handleException(Exception ex) { return ex.getMessage(); } } 💡 Why use this? • Centralized error handling • Cleaner controller code • Better API response Key takeaway: Use global exception handling to manage errors in a clean and scalable way 🚀 In the next post, we will create custom exceptions for better control 🔥 #Java #SpringBoot #BackendDevelopment #RESTAPI #LearnInPublic

🚀 DAY 17 — ResponseEntity & Exception Handling ✅ 1. CLEAR CONCEPT (VERY IMPORTANT) 🔹 ResponseEntity 👉 Used to return: Data Status code Headers 💡 Instead of just returning data, 👉 you return complete HTTP response 🔹 Example @GetMapping("/user") public ResponseEntity<String> getUser() { return ResponseEntity.ok("User found"); } 👉 Response: Body → "User found" Status → 200 OK ⚡ WHY USE ResponseEntity? ✔ Control status code ✔ Custom response ✔ Better API design 🔴 EXCEPTION HANDLING (VERY IMPORTANT) 👉 Handles errors in clean way ❌ Without Exception Handling 👉 App crashes or messy error ✅ With Exception Handling 👉 Clean error response 💻 EXAMPLE (IMPORTANT 🔥) @GetMapping("/user/{id}") public ResponseEntity<String> getUser(@PathVariable int id) { if (id == 0) { throw new RuntimeException("User not found"); } return ResponseEntity.ok("User found"); } ⚙️ GLOBAL EXCEPTION HANDLER @RestControllerAdvice public class GlobalExceptionHandler { @ExceptionHandler(RuntimeException.class) public ResponseEntity<String> handleException(RuntimeException ex) { return ResponseEntity .status(404) .body(ex.getMessage()); } } 🎯 INTERVIEW QUESTIONS (MUST 🔥) ❓ What is ResponseEntity? 👉 Used to return full HTTP response ❓ Why use ResponseEntity? 👉 To control status + response ❓ What is Exception Handling? 👉 Handling errors gracefully ❓ What is @RestControllerAdvice? 👉 Global exception handler ❓ What is @ExceptionHandler? 👉 Handles specific exception ⚡ COMMON STATUS CODES Code Meaning 200 OK 201 Created 400 Bad Request 404 Not Found 500 Server Error 💡 BEST PRACTICES ✔ Always use ResponseEntity ✔ Handle exceptions globally ✔ Return proper status codes 🔄 FLOW (IMPORTANT) 👉 Client → API → Exception → Handler → Response 💡 FINAL UNDERSTANDING 👉 ResponseEntity = control response 👉 Exception Handling = control errors 💬 Do you return proper status codes in your APIs? Day 17 done ✅ #SpringBoot #Java #BackendDevelopment #LearningInPublic #30DaysOfCode #Developers

In production Spring Boot services, scattered try-catch blocks create inconsistent API behavior. A better approach is centralized handling: ```@RestControllerAdvice public class GlobalExceptionHandler {   @ExceptionHandler(ResourceNotFoundException.class)   public ResponseEntity<ErrorResponse> handleNotFound(ResourceNotFoundException ex) {     return ResponseEntity.status(HttpStatus.NOT_FOUND)         .body(new ErrorResponse("RESOURCE_NOT_FOUND", ex.getMessage()));   }   @ExceptionHandler(MethodArgumentNotValidException.class)   public ResponseEntity<ErrorResponse> handleValidation(MethodArgumentNotValidException ex) {     return ResponseEntity.status(HttpStatus.BAD_REQUEST)         .body(new ErrorResponse("VALIDATION_ERROR", "Invalid request payload"));   }   @ExceptionHandler(Exception.class)   public ResponseEntity<ErrorResponse> handleGeneric(Exception ex) {     return ResponseEntity.status(HttpStatus.INTERNAL_SERVER_ERROR)         .body(new ErrorResponse("INTERNAL_ERROR", "Unexpected error occurred"));   } }``` Benefits we observed: - Consistent contract for error payloads - Cleaner controllers/services - Accurate HTTP semantics (400, 404, 409, 500) - Better observability and incident response A strong error model is part of API design, not just exception handling. #SpringBoot #Java #Microservices #API #SoftwareEngineering #Backend

🚀 DAY 15 — Build REST APIs (GET, POST, PUT, DELETE) ✅ 1. CLEAR CONCEPT (VERY IMPORTANT) 👉 API = way for client to communicate with server 👉 REST APIs use HTTP methods 🌐 HTTP METHODS (CORE 🔥) MethodUseGETFetch dataPOSTCreate dataPUTUpdate dataDELETEDelete data 💻 FULL EXAMPLE (VERY IMPORTANT) @RestController @RequestMapping("/users") public class UserController { // GET → fetch users @GetMapping public List<String> getUsers() { return List.of("Ashish", "Rahul"); } // POST → add user @PostMapping public String addUser(@RequestBody String name) { return "User " + name + " added"; } // PUT → update user @PutMapping("/{id}") public String updateUser(@PathVariable int id, @RequestBody String name) { return "User " + id + " updated to " + name; } // DELETE → delete user @DeleteMapping("/{id}") public String deleteUser(@PathVariable int id) { return "User " + id + " deleted"; } } 🔄 FLOW (IMPORTANT) 👉 Client (Postman / Browser) → Controller → Method executes → Response returns 📌 API EXAMPLES GET → /users POST → /users PUT → /users/1 DELETE → /users/1 🎯 INTERVIEW QUESTIONS (MUST 🔥) ❓ What is REST API? 👉 Communication between client and server using HTTP ❓ Difference: GET vs POST? 👉 GET → fetch data 👉 POST → create data ❓ Difference: PUT vs PATCH? 👉 PUT → full update 👉 PATCH → partial update ❓ What is @RequestBody? 👉 Takes data from client ❓ What is @PathVariable? 👉 Gets value from URL ⚡ BEST PRACTICES (IMPORTANT) ✔ Use proper HTTP methods ✔ Use meaningful URLs (/users) ✔ Return proper responses ✔ Keep controller clean 💡 FINAL UNDERSTANDING 👉 GET → Read 👉 POST → Create 👉 PUT → Update 👉 DELETE → Remove 💬 Did you test APIs using Postman? Day 15 done ✅ #SpringBoot #Java #BackendDevelopment #LearningInPublic #30DaysOfCode #Developers

Stop designing APIs like it's 2015. Most developers still make these 7 mistakes that silently kill performance, scalability, and developer experience. After 14 years of building distributed systems, here's what I've learned the hard way: 1. Returning entire objects when clients need 2 fields Use field filtering: GET /users?fields=name,email Your bandwidth bill will thank you. 2. No versioning strategy from Day 1 "We'll add it later" = breaking 50 clients at 2 AM. Start with /v1/ in your URL or use header-based versioning. 3. Using HTTP 200 for everything 200 with {"error": "not found"} is NOT okay. Use proper status codes: 201, 204, 400, 404, 429. 4. Ignoring pagination on list endpoints Returning 10,000 records in one response? Your database and your users are both crying. 5. Synchronous processing for long-running tasks Don't make clients wait 30 seconds. Return 202 Accepted + a polling URL or use WebSockets. 6. No rate limiting until the system crashes Rate limit from Day 1. Not after the incident postmortem. Use token bucket or sliding window algorithms. 7. Inconsistent naming conventions /getUsers, /fetch_orders, /retrieveProducts? Pick ONE style (camelCase or snake_case) and stick to it. Good API design is not about following REST rules perfectly. It's about making life easier for the developers consuming your API. Which of these mistakes have you seen (or made)? Drop your biggest API horror story below. Follow Kuldeep Singh for daily System Design & Java insights. #SystemDesign #APIDesign #Java #Microservices #SoftwareArchitecture #BackendDevelopment #SpringBoot #TechLeadership #Programming #WebDevelopment

🚀 Spring Boot – User API Upgrade (Full CRUD) Took my mini project to the next level by implementing complete CRUD operations in Spring Boot. 🧠 What I added: ✔️ GET "/users" → Fetch all users ✔️ PUT "/user/{id}" → Update user ✔️ DELETE "/user/{id}" → Delete user 💡 Now the API supports full lifecycle operations: Create • Read • Update • Delete 🔁 Architecture in action: Controller → Service → In-memory data → JSON response 🧪 Tested all endpoints using Postman and verified the complete flow. ⚠️ Also understood the importance of proper error handling (next step: exception handling instead of returning null). 💻 DSA Practice: • Move zeros to end (array manipulation) • First non-repeating character (HashMap concept) ✨ This step helped me understand how real backend systems manage and manipulate data efficiently. #SpringBoot #Java #BackendDevelopment #RESTAPI #CRUD #DSA #LearningInPublic #SoftwareEngineering

If your API waits for everything to finish… you are slowing down your users. Some operations take time: • Sending emails • Generating reports • Calling external APIs • Processing files But many developers do this synchronously. ⸻ ❌ Blocking API @PostMapping("/register") public String registerUser() { userService.saveUser(); emailService.sendWelcomeEmail(); return "User Created"; } User waits until email is sent. Slow response. ⸻ ✅ Async Processing Return response immediately: @PostMapping("/register") public String registerUser() { userService.saveUser(); emailService.sendWelcomeEmailAsync(); return "User Created"; } ⸻ ⚙️ Spring Boot Example Enable async: @EnableAsync @SpringBootApplication Async method: @Async public void sendWelcomeEmailAsync() { // send email } ⸻ 🧠 What Happens Now User Request ↓ Save User ↓ Return Response ↓ Async Email Processing Faster APIs. ⸻ ⚠️ When to Use Async Use for: • Emails • Notifications • Background jobs • Logging Avoid for: • Transactions • Payment processing • Critical operations ⸻ 💡 Lesson Fast APIs don’t do everything. They delegate work to background processing. ⸻ Day 20 of becoming production-ready with Spring Boot. Question: Do you use async processing in your APIs? #Java #SpringBoot #BackendEngineering #Performance #Async