REST API Basics for Developers

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

Most developers equate slow APIs with bad code. However, the issue often lies elsewhere. Consider this scenario: You have a query that appears perfectly fine: SELECT o.id, c.name FROM orders o JOIN customers c ON o.customer_id = c.id Yet, the API is painfully slow. Upon checking the execution plan, you find: NESTED LOOP → TABLE ACCESS FULL ORDERS → INDEX SCAN CUSTOMERS At first glance, this seems acceptable. But here's the reality: for each row in orders, the database is scanning and filtering again. If orders contain 1 million rows, that's 1 million loops. The real issue wasn’t the JOIN; it was the database's execution method. After adding an index: CREATE INDEX idx_orders_date ON orders(created_at); The execution plan changed to: INDEX RANGE SCAN ORDERS → INDEX SCAN CUSTOMERS As a result, query time dropped significantly. Key lessons learned include: • Nested Loop is efficient only when: → the outer table is small → the inner table is indexed • Hash Join is preferable when: → both tables are large → there are no useful indexes • Common performance issues stem from: → full table scans → incorrect join order → missing indexes → outdated statistics A common mistake is this Java code: for (Order o : orders) { o.getCustomer(); } This essentially creates a nested loop at the application level (N+1 query problem). Final takeaway: Don’t just write queries; understand how the database executes them. That's where true performance improvements occur. If you've resolved a slow query using execution plans, sharing your experience would be valuable. #BackendDevelopment #DatabaseOptimization #SQLPerformance #QueryOptimization #SystemDesign #SoftwareEngineering #Java #SpringBoot #APIPerformance #TechLearning #Developers #Coding #PerformanceTuning #Scalability #DistributedSystems #DataEngineering #Debugging #TechTips #LearnInPublic #EngineeringLife

Recently, I’ve been working on backend automation using Spring Boot and Java, focusing on improving how structured data flows between systems. A big part of the challenge has been handling semi-structured inputs and transforming them into consistent, usable data for downstream processes. Some of the areas I’ve been exploring: • Extracting metadata through tagging strategies • Working with hybrid data models (structured entities + flexible JSON) • Designing logic that adapts based on the available data instead of forcing rigid structures • Building automation flows that stay maintainable as requirements evolve This experience has pushed me to think more about trade-offs in data modeling and how to design systems that are resilient to change. Always interested in connecting with others working on backend systems, automation, or data-driven workflows. #Java #SpringBoot #BackendDevelopment #Automation #SoftwareEngineering

💡 Using @Transactional in a GET API — Do You Really Need It? Most developers think @Transactional is only for INSERT/UPDATE/DELETE operations… but what about GET APIs? 🤔 Let’s break it down in the simplest way possible 👇 ⸻ 🔹 What does @Transactional do? It tells Spring: 👉 “Wrap this method in a database transaction.” That means: • All DB operations inside run safely • Either everything succeeds OR everything rolls back ⸻ 🔹 But GET API only reads data… why use it? Good question 👍 Even in read operations, @Transactional can be useful in some cases: ⸻ ✅ 1. To Avoid Lazy Loading Errors If you’re using JPA/Hibernate and fetching related data (like user.getOrders()), you might face: ❌ LazyInitializationException 👉 Why? Because the DB session is already closed. 💡 Solution: Using @Transactional keeps the session open while data is being fetched. ⸻ ✅ 2. To Ensure Consistent Data Imagine: • You are reading multiple tables • Data is changing at the same time Without transaction: 👉 You might get inconsistent results With @Transactional: 👉 You get a consistent snapshot of data ⸻ ✅ 3. For Better Performance (Read-Only Mode) You can write: @Transactional(readOnly = true) 👉 This tells the database: • “I’m only reading data, not modifying it” ⚡ Result: • Better performance • Less overhead ⸻ ⚠️ When NOT to use it? Don’t blindly add it to every GET API ❌ Avoid if: • Simple single-table fetch • No lazy loading • No complex logic 👉 Because transactions also add overhead ⸻ 🔥 Simple Rule to Remember: ✔ Complex read → Use @Transactional(readOnly = true) ❌ Simple read → Skip it ⸻ 🧠 Final Thought @Transactional is not just for writing data — it’s about managing how you interact with the database safely and efficiently. ⸻ #Java #SpringBoot #BackendDevelopment #CodingTips #Developers #TechSimplified

@PathVariable vs @RequestParam – Passing URL Data While working on my Spring Boot projects, I explored how to pass data through URLs using @PathVariable and @RequestParam, and how both are used in different scenarios. 🔹 @PathVariable Used to get values directly from the URL path. It is mostly used when the value is required and represents a specific resource. Example: /users/101 → here 101 is taken as path variable 🔹 @RequestParam Used to get values from query parameters in the URL. It is commonly used for optional data like filters, search, or pagination. Example: /users?name=Rahul → here name is a request parameter Why use both? Using @PathVariable and @RequestParam properly makes APIs more clear and meaningful. @PathVariable → for identifying resources @RequestParam → for filtering or optional inputs In real projects, understanding this difference helps in designing clean and scalable REST APIs. #SpringBoot #Java #BackendDevelopment #RESTAPI #CodingJourney #LearningInPublic

Spring Boot in Real Projects — Day 19 We already know how APIs return data. But what happens when your application grows and starts handling hundreds or even thousands of tasks daily whether from a single user or many users? For example: User1 → 50 tasks   User2 → 120 tasks   User3 → 300 tasks   It's simple to fetch data for user-1 and next user-2 with 120 tasks gets heavy to fetch and for the next user-3 its hard to fetch and the API response may gets slow, to solve this Pagination & Sorting come in What is Pagination? Pagination is the process of dividing data into smaller chunks (pages) and fetching only the required portion instead of loading everything at once. What is Sorting? Sorting allows us to order data based on a specific field like createdAt, title, etc. Flow Client → Controller → Pageable → Repository → Database (applies LIMIT, OFFSET, ORDER BY) → Returns Page → Response to Client #SpringBoot #Java #BackendDevelopment #Pagination #APIDesign #SoftwareEngineering

🚀 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

Why CRUD thinking is not enough for serious backend systems Not every business problem should be modeled as simple CRUD A lot of applications start as: - Create - Read - Update - Delete And that’s fine in simple cases. But serious business systems usually have behaviors that are not well represented by CRUD. An order is not just “updated”. It can be: - placed - confirmed - cancelled - paid - expired - refunded Inventory is not just “edited”. It can be: - reserved - released - restocked - confirmed Once you model everything as generic updates, you start losing business meaning. That’s when bugs increase. Because the system no longer expresses the real rules clearly. Good backend design often means moving from: data manipulation to business behavior modeling That’s a major difference between simple coding and system design. #DDD #BackendEngineering #Java #SpringBoot #SystemDesign #SoftwareArchitecture

🚀 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

Day 28. I fixed the N+1 problem. Or at least… I thought I did. I had this: @Entity public class User {   @OneToMany(mappedBy = "user", fetch = FetchType.LAZY)   private List<Order> orders; } And I was careful. I wasn't using EAGER. I avoided obvious mistakes. Still… something felt off. The API was slow. Query count was high. That's when I checked the logs. And saw this: → 1 query to fetch users → N queries to fetch orders Again. Even after "fixing" it. Here's what was actually happening. I was mapping entities to DTOs like this: users.stream()   .map(user -> new UserDTO(     user.getId(),     user.getName(),     user.getOrders().size()  // 👈 triggers lazy load per user   ))   .toList(); Looks harmless. But user.getOrders() → triggers lazy loading → inside a loop → causing N+1 again That's when it clicked. N+1 isn't just about fetch type. It's about when and where you access relationships. So I changed it. (see implementation below 👇) What I learned: → LAZY doesn't mean safe → DTO mapping can silently trigger queries → N+1 often hides in transformation layers The hard truth: → You think you fixed it → But it comes back in a different place Writing queries is easy. Controlling when data is accessed is what makes your backend scalable. Have you ever fixed N+1… and then seen it come back somewhere else? 👇 Drop your experience #SpringBoot #Java #Hibernate #BackendDevelopment #Performance #JavaDeveloper