0

We are building a web service with an idempotent create method and we are looking for approaches on how to implement idempotency.

The created objects have unique identifier properties, named Id, which is a GUID type and assigned by the consumer.

We considered these approches:

1) Check if an object with the same Id exists

2) Also include a Version property and check if an object with the same Id and Version exists

3) Check if an object with the same Id exis but get the object from the store, create hash of it and compare it to the hash of the incoming object

What would you recommand?

Improve this question
5
  • GUIDs are supposed to be globally unique. If you assign them on the server then they will be guaranteed to be unique, so let the client assign a temporary one for creation but if you're worried about GUID clashes give it a new one when it gets stored.
    – gbjbaanb
    Commented Apr 6, 2016 at 8:57
  • @gbjbaanb: it's not the id clashes we are worried about, it's the duplication of the object.
    – dstr
    Commented Apr 6, 2016 at 10:03
  • 1
    Indempotecy simply means that if you write the same request multiple times, the resulting state will be the same as if you only did it once. What you are describing here seems to be something different. I think you are trying to avoid dirty writes. Idempotency doesn't prevent that. Can you clarify what you are looking to do?
    – JimmyJames
    Commented Apr 6, 2016 at 14:35
  • @JimmyJames: We want to able to do this so our web service consumers call the create method again if anything goes wrong on their end after calling our create method. They should call the create method with the same parameters again we will return "created" result but not create the same object again.
    – dstr
    Commented Apr 6, 2016 at 15:13
  • What is the issue with creating the object again? Are there sideeffects to object creation? The easiest solution is to create the new object and let it replace the existing one.
    – JimmyJames
    Commented Apr 6, 2016 at 15:30

1 Answer 1

Reset to default
1

You need to generate a unique hash to compare each object. Obviously you could simply compare each field in your backing store, or each important field.

You might have to think more about what happens in creation though - imagine I try to send the new-user details to SO for the userid gbjbaanb, if it fails due to one already existing, I would not want the details to be sent back to the client - or you could 'create' my user and see all my bits, or to overwrite, then you could supply a new password and hack my user. If you simply returned "success, user created" then this would not indicate to a user creating a new account that he didn't actually create a new user!

These 2 scenarios are mutually exclusive - you cannot have both working the way you want, one has to give.

Improve this answer
2
  • 1
    This is an interesting use case. In order for the call to be idempotent, the call needs to be side effect free. What this (very familiar) use case shows is that there's an expectation that creating a user is not side effect free and should not/ can not be implemented as an idempotent call.
    – JimmyJames
    Commented Apr 6, 2016 at 21:18
  • We're not going to replace/override the existing object but keep the existing one. This is a business decision. Neither we're returning the created object as a return value, just a 201 Created.
    – dstr
    Commented Apr 7, 2016 at 7:27

Your Answer

By clicking “Post Your Answer”, you agree to our terms of service and acknowledge you have read our privacy policy.

Not the answer you're looking for? Browse other questions tagged or ask your own question.