By Ronnie Mbuqe
Without a concurrency rule, the later write can overwrite an earlier change. REST-style endpoints still need an explicit policy for competing updates.
A version token can identify the record version a client edited. The server can reject a stale update rather than silently losing someone else's work.
Two editors opened the same booking; the second save could erase the first
Both screens started with version 5. One person changes the guest name and saves version 6. The other submits older values afterward. Without a conflict rule, the later write can overwrite work the second person never saw.
We will follow a resource version through a conditional update. The goal is to understand why a method, URL and representation version belong together in a useful web contract.
Practical examples: REST APIs
Fetching
GET /bookings can return the current user’s permitted bookings with filters and paging. A safe read should not quietly change data, and the response should describe an empty result differently from an unavailable server.
Creating
POST /bookings sends the information needed to create a reservation. The server rechecks availability and rules, then returns the created identifier or a useful conflict. Retry protection matters because a delayed response can tempt a client to submit the same booking twice.
Updating
PATCH /bookings/42 can change only permitted fields instead of replacing the whole record. The API checks ownership, current status and allowed transitions so an update cannot bypass the same rules used by the normal interface.
Cancelling
DELETE may mean cancellation instead of physically erasing a business record. A booking service often keeps history for refunds, audits and reporting, changes the status safely and returns a response that tells the client whether any action was taken.
Why might repeating GET and repeating POST have different consequences?
REST-style APIs use resources and HTTP methods to communicate intent.
Trace the explanation
A retrieval should not require a business-changing side effect. Creation retries need special care, and method names alone do not repair an endpoint that violates its own contract.
Source and further reading: MDN Web Docs
The same URL can ask different questions depending on the method
GET /bookings/42 asks for a representation of a resource. A documented update operation changes it, while a delete operation requests removal under the service's rules. Method, URL, headers and body together describe the request; the path alone is not the whole contract.
A GET should not be designed as a surprising way to perform a payment. Browsers, caches and other software can repeat retrievals. Matching operation semantics to method expectations helps callers reason about repetition and side effects.
Make the old version visible to the service
The first editor submits a change conditional on the resource still matching version 5. The service accepts it and advances the version. The second editor's unchanged precondition no longer matches, so the service reports a conflict rather than silently applying stale data.
HTTP can express conditional requests using validators such as an entity tag and the If-Match header. The exact API must document how it uses those mechanisms. A version check must be enforced where the change is committed, not only displayed on the screen.
The interface should then show the current record and let the person resolve the difference. Automatically repeating the old overwrite would undo the protection. This is an example of an operation with a deliberate failure outcome that helps preserve meaning.
After the first save advances the record, which version should the second editor inspect before deciding how to retry?
This checks a prediction about the worked example. It does not run server code, contact an API or change a booking.
Version 6. The second editor needs the current state and must resolve the difference; resending version 5's assumptions defeats the check.Read the explanation without the checker
Version 6. The second editor needs the current state and must resolve the difference; resending version 5's assumptions defeats the check.
Explain why a JSON response alone does not tell you whether the operation has sensible resource and concurrency semantics.
A client requests 5 pages with 20 records per page and receives every page full. How many records does it receive?
Trace the explanation
5 × 20 = 100 records. Pagination also needs a stable ordering or cursor strategy; otherwise changing data can cause records to repeat or be missed between requests.
Source and further reading: MDN Web Docs
Why should a retry not create a second payment?
Some operations have additional effects every time they run. A client needs more than repeated HTTP requests to make them safe.
A service can associate an operation identifier with a stored result and handle repeats consistently. The identifier must be checked on the server; disabling a button alone is insufficient.
See what makes the method and URL meaningful
HTTP defines the methods, headers and status codes REST uses, while JSON commonly carries the representation. The server still needs identity and permission checks plus application rules, REST organisation does not make an endpoint secure by itself.
A resource that changed behind your screen can invalidate your edit
Two people may open the same record, then submit conflicting changes. Without a concurrency check, the second save can overwrite the first person's work. A representation version or conditional request can let the service reject an edit based on stale data.
The interface then needs to explain the conflict and show a safe next step. Silently retrying with the old values can destroy the very change the check was meant to protect. A well-designed API makes this state visible instead of treating it as an ordinary success or an unhelpful generic error.
Does returning JSON automatically make an API RESTful?
No. JSON is a representation format. Resource modelling, operation semantics and other architectural choices concern how the interface behaves, not simply the punctuation of its response.
Questions about REST APIs Explained Simply
Is REST the only API style?
No. There are other styles, but REST is very common on the web.
Do beginners need REST?
If you want to understand modern web apps, REST is very useful. Almost every app that fetches data from a server, a weather app pulling today's forecast, a shop app loading product prices, is talking to a REST API behind the scenes.
Is every web API a REST API?
No. GraphQL, SOAP, RPC-style services and custom HTTP APIs are alternatives. REST is one common design approach.
What is statelessness?
It means each request should contain the information the server needs to understand that request instead of depending on hidden conversational state between calls.
Should every action be a CRUD endpoint?
No. Real business operations such as confirm, refund or send may deserve explicit action endpoints when that makes the contract clearer and safer.
How should REST APIs report errors?
They should use an appropriate HTTP status and a consistent response body that tells the client what failed without exposing sensitive internal details.
What makes an API “REST-like”
REST is an architectural style built around resources and standard HTTP behaviour. Instead of inventing an action URL for every operation, an API might expose /bookings/42 as the resource and use GET to read it, PUT or PATCH to change it and DELETE to remove it. The response uses HTTP status codes and commonly JSON so clients can understand both the data and whether the request succeeded.
Real APIs also need rules that REST alone does not solve: authentication, authorisation, validation, pagination, rate limits, versioning and consistent error responses. A clean endpoint is valuable because many clients can use the same contract, a website, mobile app or another business system, without knowing how the server stores its data internally.
Two clients edit the same record. How can an API avoid silently replacing one person's newer changes?
One reasoned response
Use a version or conditional update contract such as an ETag with If-Match. Reject a stale write so the client can reconcile rather than pretending the conflict never happened.
Source and further reading: MDN Web Docs
Example: read a resource with HTTP
A REST-style API commonly exposes resources through URLs and uses HTTP methods to describe the intended operation. A read request might look like this:
GET /api/products/42 HTTP/1.1
Host: example.test
Accept: application/json
The server might return a successful status and a JSON representation of product 42, or an error such as not found or unauthorised. The exact endpoint and response depend on the API contract. A client should check the status code, handle missing or unexpected fields, and avoid assuming that every request succeeds. For operations that change data, understand authentication, permissions, validation and retry behaviour before implementing the call.
Sources
Sources and further reading
A closer lookA retry must not create another booking
A client sends a booking request. The server saves it, but the response is lost. A second identical create request could produce a duplicate unless the service recognises the operation.
Work through the distinction
A design can accept an idempotency key and store the result for that operation. The server must enforce the rule and handle concurrent retries; disabling a button alone is insufficient. A timeout describes what the client observed, not whether the booking exists.
Does a timeout prove the booking was not saved?
Choose an answer to see feedback. You can try again.
Show the answer and explanation
No, the result is uncertain. A design can accept an idempotency key and store the result for that operation. The server must enforce the rule and handle concurrent retries; disabling a button alone is insufficient. A timeout describes what the client observed, not whether the booking exists.