What is API Idempotency and Why Is It Important?

Поделиться
HTML-код
  • Опубликовано: 22 ноя 2024

Комментарии • 75

  • @pro_mode14
    @pro_mode14 2 года назад +7

    The Simplicity with which you explain things is just awesome!, also thanks for sharing the reference article.

  • @jeromearenas8028
    @jeromearenas8028 Год назад +1

    They never teach this in schools. Saves me alot of time and headaches. Im trying to work out Payment channel apis to my app and I don't know what the hell is the x-idempotency-key in request header stated in the documentation. You earned a subscriber.

  • @maximyarmolik1726
    @maximyarmolik1726 29 дней назад

    Great video and explanation.
    It got me thinking though on how to avoid problems when say the creation runs for 5 seconds, but you got the same request in 1 second after receiving the first one

  • @qasimarthuna9254
    @qasimarthuna9254 2 года назад +14

    I have already implemented this thing but I don't know it is actually a concept in programming.
    Thank you Daniel.
    Now I can show to my boss that I have used something unusual. And which is called idempotent.
    😃😃

  • @taylormonacelli
    @taylormonacelli 2 года назад +8

    So clear and concise. Thank you!

  • @jamesmcintyre
    @jamesmcintyre Год назад +3

    Awesome explanation AND presentation! I’ve built countless rest endpoints and consumed countless more clientside but always felt there’s too much room for these edge cases and furthermore wondered how could clients compensate for the edge cases. Thanks! Subscribed!🎉

  • @XLpacman805
    @XLpacman805 11 месяцев назад

    Your videos are so good I can feel my brain consuming and enjoying the information.

  • @GáborNagy-v7z
    @GáborNagy-v7z Год назад

    Just such a simple and great explanation. Thanks!

  • @abusamer9
    @abusamer9 2 года назад

    Thanks for this video !simple and clean explanation

  • @antwanwimberly1729
    @antwanwimberly1729 11 месяцев назад

    Keep in mind if you did use a cache, it would need to be distributed . A cache on a web server in a load balanced and distributed environment would lead to a miss. Without a distributed cache, the database would need to be the source of record (a uniqueness constraint would do it).

  • @jamesforster2720
    @jamesforster2720 2 года назад

    Super clear explanation, thank you!

  • @VenkataswamiMadala33
    @VenkataswamiMadala33 2 года назад +1

    Really nice 👍 simply explained

  • @abdelrahmanmostafa9489
    @abdelrahmanmostafa9489 5 месяцев назад

    without proper rate limit that can lead to DOS by creating infinite requests with new tokens, overwhelming the database. you can intercept the request and change the token!

  • @christianibiri
    @christianibiri 2 года назад +1

    Great video!!!! thanks Daniel... this channel is one of the best!!!

    • @BeABetterDev
      @BeABetterDev  2 года назад

      Thanks Christian! Glad you enjoyed :)

  • @malcolmfeatonby3812
    @malcolmfeatonby3812 2 года назад +2

    Awesome walk through! Thanks for the great content.

    • @BeABetterDev
      @BeABetterDev  2 года назад +1

      Glad you enjoyed it Malcolm and thank you!

  • @maximilianworner1288
    @maximilianworner1288 2 года назад +2

    Great video 👍 Perfect explanation right to the point!

  • @mrrishiraj88
    @mrrishiraj88 2 года назад +1

    Thanks

  • @pupfriend
    @pupfriend 2 года назад +2

    Great explanation!

  • @Ace-kt8ry
    @Ace-kt8ry 2 года назад +1

    thank you

  • @256JD
    @256JD 2 года назад +2

    Thank you, it was a very clear explanation. I have a doubt, about the case the retry is made before the first request has been processed by the server. I only think of returning an response stating the request is in process. What should the server return in that case?

    • @rngouveia
      @rngouveia 2 года назад

      Client-side retries only make sense in very fast operations, and in this case, the retry time should be configured to be long enough. If the client's request is stimulating a long-running process, then you would need to design the solution differently. One common way is making the client's call be asynchronous and the server be the one responsible for doing everything that needs to be done (and retrying if it needs to). The server would also offer API's that inform in which stage the processing of the request is.

  • @sagarajayathilaka
    @sagarajayathilaka 2 года назад +1

    Nice explanation

  • @Vinod_Kumar827
    @Vinod_Kumar827 2 года назад +1

    Amazing video, thanks

  • @RayanMADAO
    @RayanMADAO Год назад +1

    I don't understsand the logic behind when the client creates a new token/uuid? If the client wanted to create 2 accounts they'd create a different token on the 2nd request, but if the client wanted to create 1 account and didn't receive a response on the first try and they clicked again wouldn't that create a different token and the server wouldn't know it's the same request?

    • @jinjinjiang6180
      @jinjinjiang6180 3 месяца назад

      Double-clicking is a different issue from what the author is trying to explain. You can address it by disabling the button immediately after the first click, even before the client receives a response. If a second click still gets through, it would be treated as a completely new request.

  • @yacovskiv4369
    @yacovskiv4369 2 года назад +4

    I am assuming the tokens maintained in the stale store need to outlive the user session? Because if the user remains logged in and retries after the stored tokens are deleted, we'd run into the same issue all over again.

    • @little-by-little-one-trave1770
      @little-by-little-one-trave1770 2 года назад +3

      Or we can also have a acknowledgement from client indicating that request is successfully handled and discard the token, along with your solution. Acknowledgement solution on itself may not work as acknowledgement itself can get lost.

    • @AlvinC-sz3li
      @AlvinC-sz3li 2 года назад +1

      User session shouldn't have anything to do with the token here. Token should be stored with your DB record.

  • @herbievanbeveren1314
    @herbievanbeveren1314 Год назад

    Very nice!

  • @markelca
    @markelca Год назад +2

    How the client in the second call it's supposed to generate the same token id as the first one? Won't just generate a brand new one? Didn't get that part

    • @mn109
      @mn109 Год назад

      I didn't get that part either...

    • @jinjinjiang6180
      @jinjinjiang6180 3 месяца назад

      The second call is a retry, so it will reuse all the information from the first call, including the same token.

    • @jinjinjiang6180
      @jinjinjiang6180 3 месяца назад

      Retry differs from sending a new request when a new token is generated.

  • @illegalcall
    @illegalcall 6 месяцев назад

    How does this work when there is a load balancer. Meaning, the first time token is saved in a different server but the 2nd request goes to a different server because of a load balancer?

  • @santhoshn3766
    @santhoshn3766 2 года назад

    Thanks for sharing!!

  • @farzadb
    @farzadb 2 года назад

    Great video as usual 👍

  • @marimbanation4118
    @marimbanation4118 2 года назад +1

    really nice explanation

  • @lizedine
    @lizedine 2 года назад +2

    how exactly is the client supposed to generate the request token, is it the same idea as before (i.e. using some specific hash function)? if so, how would multiple clients know what function to use if this were a publicly exposed API? sorry if this is a basic question, but that was the only part confusing me. thanks in advance, awesome video.

    • @RAJU9622
      @RAJU9622 2 года назад +1

      Actually client won’t call the hash function, api gateway have the function (assume like lambda function) so any client calls the Api that function will execute . The hash will be generated based on payload basically all this hash function code will be in backend. If payload is same it know the request came before as stale store have this hash.

    • @kaypakaipa8559
      @kaypakaipa8559 2 года назад

      @@RAJU9622 are u saying im terms of flow,
      1. Client call api
      2. Lambda hash func executes
      3. Lambda calls or fowards request to the actual api
      Is this the flow? Seems expensive

    • @RAJU9622
      @RAJU9622 2 года назад

      @@kaypakaipa8559 yes it’s expensive but need to do

  • @MrYamrajji
    @MrYamrajji 2 года назад

    Hello I am really learning from you aws videos but I don't know how to reach you. I am facing a cuncurrency limit issue after running glue job. I am new to my project but I don't know what can help. can you suggest me something.

  • @SentryProductions1
    @SentryProductions1 8 месяцев назад

    OIDC!

  • @liuleo4073
    @liuleo4073 2 года назад

    Could you tell me what software is used to draw the picture?

    • @BeABetterDev
      @BeABetterDev  2 года назад

      Hi this is done with Google slides.

  • @shintaii84
    @shintaii84 2 года назад

    Can you make a similar video on the same thing but now with external api’s that you not control? For me that is an issue. Where the external api is not idempotent and I need to handle this myself. Currently when i need to retry i first do a get request to see if it is there, if yes mark completed. If no send request again.

  • @ijanijigar
    @ijanijigar 2 года назад +2

    Thank you for sharing this.
    A small doubt.. let's say my response is huge with many json fields which are the result of many operations at service layer. If any retry happens, my server can check for the token in store but how can I generate the identical response in this case? I think I shouldn't store each response in any kind of store and map it with token otherwise these big blobs may take significant space.
    Can you please suggest any way around this?
    Thank you once again sir.

    • @AlvinC-sz3li
      @AlvinC-sz3li 2 года назад

      Your response should be generated by your DB record.

  • @serggie3
    @serggie3 2 года назад +1

    I like my entity-creation APIs to return the created entity. I don't want them to just return { "success": true }. Is that possible with these tokens?

    • @BeABetterDev
      @BeABetterDev  2 года назад

      Hi serggie, yes thats a much more standard pattern and what I do in my usual API implementations.

    • @victorliendo2010
      @victorliendo2010 2 года назад

      Maybe you can link or attach the resource that has been created (or the response as it is supposed to be sent to the client) , then when the token comes in again, you could retrieve the complete response ...

    • @kaypakaipa8559
      @kaypakaipa8559 2 года назад

      Return id of resource, and success true

  • @nahuelleiva8460
    @nahuelleiva8460 2 года назад +1

    This can be developed too with some kind of "cache" approach, right? Let's say I don't want to store my tokens in the DB because they refresh after certain periods of time, and instead, I use a temporal cache to store them and as long as the token hasn't refreshed, whenever the client makes an API request I check my cache and if the token already exists I can return a { "success": true } response to the client. Is that correct?

    • @santhoshn3766
      @santhoshn3766 2 года назад

      +1

    • @BeABetterDev
      @BeABetterDev  2 года назад +4

      Hi Nahuel, good question. A cache is certainly a viable solution to store the tokens. I would just make sure you use a distributed cache so that any host will be able to assess if it has seen a similar request in the past (even if it was processed on a different host). A TTL feature on the cache is also a good idea!

    • @nahuelleiva8460
      @nahuelleiva8460 2 года назад

      @@BeABetterDev nice! Thanks for the insight :) and thanks for the quick response and the content! I hope you are having a nice day.

    • @AlvinC-sz3li
      @AlvinC-sz3li 2 года назад +1

      But do you still want to make the API idempotency after cache expires?

  • @GozeLove
    @GozeLove 2 года назад

    Is there a code example of this concept?

  • @timothyanderson2166
    @timothyanderson2166 2 года назад

    Apparently, I've been pronouncing idempotency COMPLETELY wrong for a long time.

  • @antwanwimberly1729
    @antwanwimberly1729 11 месяцев назад

    #wan

  • @berkanbilgin1472
    @berkanbilgin1472 Год назад

    witn another word, you are NOT making it 100% idempotent by simply using PUT, you are just saying your api consumer that "this is a put request, so you should expect the same result as long as you do the same request" but actual idempotency is depent on your logic. If your API method has a logic which creates a record in database every single time its requested, then having a PUT method does NOT provide any idempotency automagically. Again its just a convention, like a documentation of your API. You actual implementation of the API method is the one if it is actually idempotent or not.

  • @laxmisuresh
    @laxmisuresh 2 года назад

  • @Ace-kt8ry
    @Ace-kt8ry 2 года назад +1

    thank you