4 ms·
We're dancing around a lot of the real reasons APIs change though. It might work if it's a completely self-contained system, but many real-world systems are de
by hakfoo 5y ago
We're dancing around a lot of the real reasons APIs change though. It might work if it's a completely self-contained system, but many real-world systems are dealing with externally-imposed changes. You're talking to another API downstream, or a piece of hardware that gets replaced, or a database which no longer offers the same information.
Imagine, for example, you provide a payments API that said "You need account and routing number." One day, the banking regulator says "we also need the date of birth for validation." You have to break the API signature, and you can't really offer a backwards-compatible version. Anyone building a product on top of your API has to make similar adjustments, ether internally or by forcing the upstream user to supply the date of birth.
- jensneuse 5y agoVery true. It's impossible to not break an API in some cases. The solution described should give developers an easy way to correct design decisions or deprecate parts of the API that have changing dependencies. It's more about improving the DX of breaking APIs to improve or evolve them. The case you describe cannot be solved and all affected clients will accept that. I guess if regulators ask for such a big change, there will be enough time for all involved parties to prepare for the change.