Optimistic Concurrency in an HTTP API with ETags & Hypermedia

How do you implement optimistic concurrency in an HTTP API? There are a couple of different ways, regardless of what datastore you're using in the backend. You can leverage the ETag header in the HTTP Response to return a "version" of the resource that was accessed. When a client then needs to perform some operation on the resource, they send an If-Match header apart of the request with the value being the result of ETag from the initial GET request. Another option is to leverage hypermedia by returning URIs for actions relevant to a resource that include the version apart of the URI. This enables concurrency to be completely transparent and does not require any knowledge from the client.

🔗 EventStoreDB

💥 Join this channel to get access to source code & demos!

🔥 Don't have the JOIN button? Support me on Patreon!

Node & Express Example by Oskar Dudycz

0:00 Intro
0:33 Optimistic Concurrency
2:45 Cosmos Document Store Example
5:40 EventStore Event Stream Example
8:58 Hypermedia

#softwarearchitecture #softwaredesign #httpapi

[IvanRandomDude]

Hypermedia! That's what REST is all about. Many people wrongly think that REST is just returning json from controllers. Wrong. REST is much more,

[ahmedanwer]

Its great that you explained such topic and currently we are implementing optimistic concurrency in our app.

[farzadmf]

Just wanted to thank you for all your great videos, keep them coming 🙂

[rstart]

It is worth to mention that event store db has write and version control guarantees! So any concurrent calls are safe by default (as long as you provide version).
Kafka, for instance, can’t give you this type of guaranty for optimistic concurrency

[thedacian]

In entity framework we have implemented optimistic concurrency pattern which works easily with sql server timestamps

[MrEnsiferum]

What microservices said to optimistic concurency? U have no power here