Skip to main content
OverflowAI is here! AI power for your Stack Overflow for Teams knowledge community. Learn more

New answers tagged

0 votes

"Public APIs are forever: Only one chance to get it right"?

Changing a widely used API is a pain. You need a very good reason. Many languages allow you to mark things as “deprecated”. So the first step is to provide a better API, mark the old one as deprecated,...
gnasher729's user avatar
  • 45.7k
0 votes

"Public APIs are forever: Only one chance to get it right"?

It is true to in the sense that if you don't want to cause working software to stop working, then you should keep public API's around forever. You can introduce new API's, but you can't remove older ...
JacquesB's user avatar
  • 59.7k
0 votes

"Public APIs are forever: Only one chance to get it right"?

Breaking changes must be avoided at all cost, except if there is a VERY good reason for it. Every time you introduce a breaking change it will exponentially ripple to all dependent software. Much of ...
Alberto Salvia Novella's user avatar
3 votes

Idempotency for a financial transaction API

You mentioned an account table and a pot table. Implicit in the question, there must also be a ledger table, which we can use to audit a sequence of transactions. It only makes sense for the client to ...
J_H's user avatar
  • 7,148
4 votes
Accepted

Idempotency for a financial transaction API

The goal is to achieve idempotency on the endpoint so that if two concurrent requests arrive at the service, the amount will be transferred only once. This may be a little bit tangled, as the process-...
VoiceOfUnreason's user avatar
5 votes

Is there a name for this API/type design principle? (I think of it as "state hygiene")

This is a type invariant - a condition that is true for an instance of a type for an external observer for the duration of a valid program. In most imperative languages invariants are enforced ...
Basilevs's user avatar
  • 1,984

Top 50 recent answers are included