Spring Boot API: @PathVariable vs @RequestParam

Why I prefer PATCH over PUT for most updates in real-world APIs At first glance, PUT looks cleaner. It replaces the entire resource and is idempotent — meaning sending the same request multiple times results in the same state. But in real systems, that can become risky. With PUT, if the client doesn’t send the full object, missing fields may get overwritten as null. In large or evolving schemas, this can silently corrupt data. Example: If a user entity has 10 fields and the frontend only sends 1 updated field using PUT, the remaining 9 can unintentionally be reset. That’s where PATCH becomes safer. PATCH allows partial updates — only the fields provided are modified. The rest remain untouched. It also reduces payload size and works better with frontend-driven forms. ⚠ Idempotency isn’t about the HTTP verb alone — it depends on how you design the operation. A PATCH that sets status = ACTIVE is idempotent. A PATCH that increments balance += 100 is not. Lesson: Choosing between PUT and PATCH isn’t about syntax. It’s about data safety, retries, and how your API behaves under real production traffic. #BackendEngineering #APIDesign #REST #Java #SpringBoot #SystemDesign #SoftwareArchitecture

@RequestBody vs @RequestParam vs @PathVariable in Spring REST Choosing the right way to receive data in a controller directly affects the clarity of your API design. In practice: @PathVariable Use it to identify a specific resource. Example: /users/{id} @RequestParam Use it for filtering, searching, or optional parameters. Example: /users?status=ACTIVE @RequestBody Use it to send structured data when creating or updating a resource. Why this distinction matters: Keeps URLs meaningful and predictable Improves API readability for consumers Avoids mixing resource identity with request payload Clear parameter usage is a small detail that significantly improves long-term API maintainability. 💬 In your APIs, do you follow a strict rule for choosing between these three? #SpringREST #SpringBoot #Java #APIDesign #BackendDevelopment #SpringFramework

If you're still just using .get() and .then(), you're only using 10% of Rest Assured's power. Here is the architecture-level checklist.

If you're still just using .get() and .then(), you're only using 10% of Rest Assured's power. Here is the architecture-level checklist The List: 🏗️ baseURI & basePath: The foundation for DRY (Don't Repeat Yourself) code. 🧩 given(): The start of every BDD-style technical "given" state. 🔍 spec(): For implementing RequestSpecBuilder and ResponseSpecBuilder for global configurations. 🔐 auth(): Supporting OAuth2, Basic, and Preemptive authentication flows. 📦 body(): The core for sending JSON/XML payloads. 🛡️ when(): Triggering the actual request action. ✅ then(): Transitioning into the validation phase. 📉 extract(): Crucial for retrieving data (like tokens) for downstream tests. 🎯 jsonPath(): Deep-diving into JSON responses with GPath expressions. 🛠️ header(): For setting and validating technical metadata. 🔄 queryParam(): Handling dynamic URL filtering. 🧪 assertions(): Using Hamcrest matchers like equalTo() and hasItems(). 📊 log().all(): Essential for "Proof of Work" debugging. ⏳ time(): Measuring API performance and latency. 📦 as(): For seamless de-serialization into POJO classes. -x-x- Learn API Automation using Java & RestAssured: https://lnkd.in/gZWg7xD6 #japneetsachdeva

𝗢𝗻𝗲 𝗦𝗽𝗿𝗶𝗻𝗴 𝗔𝗻𝗻𝗼𝘁𝗮𝘁𝗶𝗼𝗻 𝗧𝗵𝗮𝘁 𝗖𝗮𝗻 𝗦𝗮𝘃𝗲 — 𝗼𝗿 𝗕𝗿𝗲𝗮𝗸 — 𝗬𝗼𝘂𝗿 𝗔𝗽𝗽 @Transactional looks harmless. Add it to a method. Your data becomes “safe”. Until it doesn’t. Here’s what actually happens when Spring sees @Transactional: ➡️ Spring creates a proxy around your class ➡️ The proxy opens a transaction before the method runs ➡️ Your method executes ➡️ If it completes successfully → COMMIT ➡️ If a runtime exception occurs → ROLLBACK So far, so good. But here’s the catch 👇 Transactions only work when the call goes through the proxy. That means this breaks transactions silently: ❌ A method calling another @Transactional method inside the same class (self-invocation) Why? Because the call never leaves the object — the proxy is bypassed. No proxy → no transaction → no rollback. Another common surprise: 🔸 By default, Spring rolls back only on unchecked exceptions 🔸 Checked exceptions will still COMMIT unless configured And one more: 🔸 @Transactional belongs at service boundaries, not controllers, not repositories, not everywhere. When used correctly, @Transactional gives you: ✅ Consistent data ✅ Clear business boundaries ✅ Safe rollback behavior When misunderstood, it creates: ❌ Phantom bugs ❌ Partial writes ❌ False confidence My rule of thumb: If you can’t explain how @Transactional works internally, you probably shouldn’t use it yet. If you had to debug one issue caused by @Transactional, what was it? 👇 Let’s learn from each other. #SpringBoot #Java #Transactional #BackendDevelopment #SoftwareArchitecture #SpringFramework

📌 Exception Handling in Spring – Real-Time Examples In real applications, exceptions are not errors — they are signals. How you handle them decides API stability, user experience, and debugging speed. 🔹 Why Proper Exception Handling Matters ❌ Unhandled exception → 500 error ❌ Poor error message → Confused frontend ❌ No logs → Painful production support ✅ Proper handling = clean APIs + faster debugging 🔹 1️⃣ Centralized Exception Handling (@ControllerAdvice) Instead of handling exceptions in every controller, Spring allows central handling. 🔧 Real-Time Example Scenario: User calls an API with an invalid ID. Problem: Service throws EntityNotFoundException. Solution: Catch it globally Return meaningful HTTP response Result: { "errorCode": "USER_NOT_FOUND", "message": "User with given ID does not exist" } 👉 Cleaner controllers, consistent responses. 🔹 2️⃣ Custom Exception for Business Logic 🔧 Real-Time Example Scenario: User tries to withdraw more balance than available. Exception: InsufficientBalanceException Handled as: HTTP Status → 400 BAD REQUEST Clear message for frontend 👉 Business failures ≠ System failures. 🔹 3️⃣ Handling Validation Errors (@Valid) 🔧 Real-Time Example Scenario: Frontend sends empty email or invalid phone number. What happens: Validation fails MethodArgumentNotValidException is thrown Response returned: { "email": "Email must not be empty", "phone": "Invalid phone number" } 👉 Frontend gets field-level errors instantly. 🔹 4️⃣ Handling Database Exceptions 🔧 Real-Time Example Scenario: Duplicate entry for unique email. Exception: DataIntegrityViolationException Handled as: HTTP Status → 409 CONFLICT Message → “Email already exists” 👉 Prevents exposing DB-level errors to users. 🔹 5️⃣ Logging + Exception Handling (Production Must) Best practice: Log exception with requestId Don’t expose stack traces to clients Return generic message for unexpected errors 👉 Logs help backend teams during production incidents. 🧠 Key Takeaway Controllers should focus on logic, Exception handling should be centralized, meaningful, and safe. 💬 How do you handle exceptions in your Spring applications — Controller level or Global level? #Java #SpringBoot #BackendDeveloper #ExceptionHandling #Microservices #ProductionSupport #SoftwareEngineering

🚀 Day 18/100 - application.properties VS application.yml ➡️ #SpringBoot supports two primary configuration file formats to define application settings: 🔸application.properties 🔸application.yml Both do the same job, but they differ in syntax, readability, and structure. ➡️ Key Differences at a Glance 📌 application.properties 🔹Format 👉 Key–value pairs 🔹Syntax 👉 key=value 🔹Readability 👉 Less readable for nested values 🔹Structure 👉 Flat 📌 application.yml 🔹Format 👉 Hierarchical, indentation-based 🔹Syntax 👉 YAML syntax using indentation 🔹Readability 👉 Much more readable for nested/grouped configs 🔹Structure 👉 Tree-like / hierarchical ➡️ When to Use Which? 📌 Use application.properties when: 🔸Configuration is small 🔸You prefer a flat, straightforward format 📌 Use application.yml when: 🔸Configuration is large or deeply nested 🔸You want better readability and structure 🔸You work with multiple profiles in one file Next post: https://lnkd.in/d4aXBtEV Previous post: https://lnkd.in/dDbNWuYt #100Days #Java #SpringBoot #Configurations #SpringBootConfigurations #WebDevelopment #SoftwareEngineering

🌐 **Unlocking the Power of JSON in API Requests!**🌐 In today's digital landscape, APIs (Application Programming Interfaces) are the backbone of modern applications, enabling seamless communication between different software systems. At the heart of this communication lies **JSON (JavaScript Object Notation)** – a lightweight, easy-to-read format that has revolutionised how data is exchanged over the web! 🚀 **Why JSON is the Preferred Choice for API Requests:** 1. **Simplicity & Readability**: JSON's straightforward syntax makes it easy for developers to read and write data quickly. 2. **Lightweight**: JSON's compact structure ensures faster data transmission, reducing latency in API calls. 3. **Language Agnostic**: JSON is supported by virtually all programming languages, making it a versatile choice for developers. 4. **Structured Data**: JSON allows for complex data structures, enabling rich data representation in API requests and responses. 5. **Easy Integration**: Most modern web frameworks and libraries have built-in support for JSON, simplifying API development. Whether you're building RESTful APIs or working with microservices, leveraging JSON for your API requests can significantly enhance your application's performance and developer experience. Embrace the power of JSON and take your APIs to new heights! 🌟 ====================== https://github.com/zoma00 ====================== #APIDevelopment#JSON#WebDevelopment#TechInnovation #SoftwareEngineering#DataExchange #Programming

🚨 𝐒𝐭𝐨𝐩 𝐀𝐬𝐤𝐢𝐧𝐠 𝐘𝐨𝐮𝐫 𝐎𝐛𝐣𝐞𝐜𝐭𝐬 𝐐𝐮𝐞𝐬𝐭𝐢𝐨𝐧𝐬 (𝐓𝐡𝐞𝐲’𝐫𝐞 𝐍𝐨𝐭 𝐆𝐨𝐨𝐠𝐥𝐞) Ever seen code like this? 𝘪𝘧 (𝘢𝘤𝘤𝘰𝘶𝘯𝘵.𝘨𝘦𝘵𝘉𝘢𝘭𝘢𝘯𝘤𝘦() >= 𝘢𝘮𝘰𝘶𝘯𝘵) {   𝘢𝘤𝘤𝘰𝘶𝘯𝘵.𝘸𝘪𝘵𝘩𝘥𝘳𝘢𝘸(𝘢𝘮𝘰𝘶𝘯𝘵); } Looks innocent… but this tiny 𝘪𝘧 is quietly hurting your design Welcome to 𝐓𝐞𝐥𝐥, 𝐃𝐨𝐧’𝐭 𝐀𝐬𝐤. 🤔 𝐖𝐡𝐚𝐭’𝐬 𝐠𝐨𝐢𝐧𝐠 𝐰𝐫𝐨𝐧𝐠? You: ◆ ask an object for its data ◆ then decide outside what to do Congrats, you’ve turned your object into a 𝐠𝐥𝐨𝐫𝐢𝐟𝐢𝐞𝐝 𝐝𝐚𝐭𝐚 𝐡𝐨𝐥𝐝𝐞𝐫 Business rules start living 𝘦𝘷𝘦𝘳𝘺𝘸𝘩𝘦𝘳𝘦 except where they belong. 𝐓𝐡𝐞 𝐁𝐞𝐭𝐭𝐞𝐫 𝐖𝐚𝐲 Instead of asking: if (account.getBalance() >= amount) { ... } Just tell it: account.withdraw(amount); Let the object decide if it can withdraw. ◆ Rules stay in one place ◆ Changes are safer ◆ Code reads like a story, not an interrogation 𝐀𝐫𝐞 𝐆𝐞𝐭𝐭𝐞𝐫𝐬 𝐄𝐯𝐢𝐥? No. Great for logging, displaying, and debugging. But if they drive business decisions — it’s time to refactor. 🧠 𝐑𝐮𝐥𝐞 𝐨𝐟 𝐓𝐡𝐮𝐦𝐛 𝐠𝐞𝐭𝐒𝐨𝐦𝐞𝐭𝐡𝐢𝐧𝐠() → 𝐢𝐟 → 𝐝𝐨𝐒𝐨𝐦𝐞𝐭𝐡𝐢𝐧𝐠() Pause That logic probably belongs inside the object. 𝐅𝐢𝐧𝐚𝐥 𝐓𝐡𝐨𝐮𝐠𝐡𝐭 Objects should have behavior, not just data. 𝐀𝐬𝐤 𝐥𝐞𝐬𝐬. 𝐓𝐞𝐥𝐥 𝐦𝐨𝐫𝐞. Have you seen this pattern in your codebase? 😅 👉 Yes / Too often / Guilty #SoftwareEngineering #CleanCode #OOP #TellDontAsk #Java #ProgrammingPrinciples

APIs don’t break People misuse POST, PUT & PATCH. If your backend behaves weirdly, 90% of the time the problem isn’t Spring Boot — it’s incorrect HTTP semantics. Here’s the clarity most developers miss 👇 POST → Create a new resource → Server owns the ID → Never assume idempotency PUT → Replace the entire resource → Same request, same result (idempotent) → Insert or update depends on design, not magic PATCH → Partial update → Only changed fields travel over the wire → Cleaner, safer, more efficient What matters more than annotations 👇 • @RequestBody isn’t optional — it’s how JSON becomes state • entityManager.merge() decides update vs insert, not your controller • PATCH needs dynamic field handling, hence ObjectMapper • Good APIs protect IDs — they don’t trust clients Hard truth 👇 REST isn’t about endpoints. It’s about intent, guarantees, and predictability. Design APIs that make wrong usage impossible, not ones that “work most of the time”. If you’re building backend systems that need to scale, this distinction is non-negotiable. #BackendEngineering #SpringBoot #RESTAPI #APIDesign #Java #SoftwareArchitecture #CleanCode