Hare Krishna’s Post

View profile for Hare Krishna, graphic

Software Development Engineer @Amazon

𝗘𝘃𝗲𝗿 𝘄𝗼𝗻𝗱𝗲𝗿𝗲𝗱 𝘄𝗵𝘆 𝘀𝗼𝗺𝗲 𝗔𝗣𝗜 𝗿𝗲𝗾𝘂𝗲𝘀𝘁𝘀 𝗰𝗮𝗻 𝗯𝗲 𝗿𝗲𝗽𝗲𝗮𝘁𝗲𝗱 𝗲𝗻𝗱𝗹𝗲𝘀𝘀𝗹𝘆 𝘄𝗶𝘁𝗵𝗼𝘂𝘁 𝗰𝗮𝘂𝘀𝗶𝗻𝗴 𝗰𝗵𝗮𝗼𝘀, 𝘄𝗵𝗶𝗹𝗲 𝗼𝘁𝗵𝗲𝗿𝘀 𝗻𝗲𝗲𝗱 𝘁𝗼 𝗯𝗲 𝗵𝗮𝗻𝗱𝗹𝗲𝗱 𝘄𝗶𝘁𝗵 𝗰𝗮𝗿𝗲? 🤔 This depends on the 𝗶𝗱𝗲𝗺𝗽𝗼𝘁𝗲𝗻𝗰𝘆 nature of the API. Let's understand what do we mean by idempotent? 𝗜𝗱𝗲𝗺𝗽𝗼𝘁𝗲𝗻𝘁 𝗢𝗽𝗲𝗿𝗮𝘁𝗶𝗼𝗻𝘀: 𝗧𝗵𝗲 𝗦𝘂𝗽𝗲𝗿𝗵𝗲𝗿𝗼𝗲𝘀 𝗼𝗳 𝗦𝘁𝗮𝗯𝗶𝗹𝗶𝘁𝘆 Imagine you’re managing a banking app. You have an endpoint to set a customer's account balance 💵 : 𝙿𝚄𝚃 /𝚊𝚌𝚌𝚘𝚞𝚗𝚝𝚜/𝟷𝟸𝟹𝟺𝟻/𝚋𝚊𝚕𝚊𝚗𝚌𝚎 { "𝚋𝚊𝚕𝚊𝚗𝚌𝚎": 𝟻𝟶𝟶𝟶 } You send a request to set the balance to Rs. 5000. But, oops! You hit the "send" button three times by accident. No worries! Thanks (or no thanks!) to the 𝗶𝗱𝗲𝗺𝗽𝗼𝘁𝗲𝗻𝘁 nature of the PUT request, the account balance will still be Rs. 5000. Whether you send it once or a hundred times, the outcome is the same (better luck next time!). This makes retrying failed requests safe and predictable. 𝗡𝗼𝗻-𝗜𝗱𝗲𝗺𝗽𝗼𝘁𝗲𝗻𝘁 𝗢𝗽𝗲𝗿𝗮𝘁𝗶𝗼𝗻𝘀: 𝗛𝗮𝗻𝗱𝗹𝗲 𝘄𝗶𝘁𝗵 𝗖𝗮𝗿𝗲 Now, let’s switch gears. Say your app also allows to transfer money 🏦 : 𝙿𝙾𝚂𝚃 /𝚊𝚌𝚌𝚘𝚞𝚗𝚝𝚜/𝟷𝟸𝟹𝟺𝟻/𝚝𝚛𝚊𝚗𝚜𝚏𝚎𝚛 { "𝚊𝚖𝚘𝚞𝚗𝚝": 𝟷𝟶𝟶, "𝚝𝚘𝙰𝚌𝚌𝚘𝚞𝚗𝚝": "𝟼𝟽𝟾𝟿𝟶" } You send a request to transfer Rs. 100 to account 67890. But then, your internet hiccups, and you click "send" again... and again. Each click results in an additional Rs. 100 being transferred! Because POST is 𝗻𝗼𝗻-𝗶𝗱𝗲𝗺𝗽𝗼𝘁𝗲𝗻𝘁, each request creates a new transaction, potentially draining the account unintentionally. 𝗪𝗵𝘆 𝗜𝘁 𝗠𝗮𝘁𝘁𝗲𝗿𝘀? Reliability: Idempotent operations ensure that retrying requests (due to network issues or user error) doesn’t cause unintended side effects. Safety: Developers can design APIs that are resilient to failures and reduce the risk of duplications. Simplicity: Debugging and maintaining systems becomes easier when repeated actions produce consistent results. Next time you design an API or troubleshoot a network glitch, remember the magic of idempotency! #APIs #SoftwareEngineering #WebDevelopment #TechInsights #Idempotency #BankingTech

To view or add a comment, sign in

Explore topics