> If it doesn't get fixed, switch endpoints or switch jobs.
At work a large part of my job is writing integrations with other systems our customers have. As an example, just recently an integration failed due to malformed XML. This was an XML file our program receives from another system our customer has bought, based on their spec.
The error was that while the XML header said the encoding was UTF-8, the actual data was Windows-1252 encoded...
The other system had bi-yearly releases, so any fix was months away, assuming their developers even understood what the issue was... And getting our customer to switch system is out of the question, at least short-term. Meanwhile our customer wanted the integration working ASAP.
So, I'd rather code a check, make our customer happy and keep my otherwise quite nice job, than quit and leave our customer stranded.
> If it doesn't get fixed, switch endpoints or switch jobs.
Uhhhhh, this is not realistic? If I have to quit my job or switch services every time those services have a bug I'm going to be switching jobs every other week.
Anyways, I think the author is actually looking for something along the lines of gRPC, where your constraints are far stricter and easier to enforce. Option types don't even really make sense for what they're after from what I could tell.
Switching endpoints may not be option. It's probably not. Why would your company have two endpoints that do the same thing. If it's a third party service you could switch to a competitor but that's not that simple either.
Switching jobs? I mea yea you could but again that's not exactly an option for a lot of people. Particularly in the short term.
Mean while your app is stuck on a loading screen with an infinite spinner and bad reviews are flowing into the app store.
In many companies, there's also option C - fix it yourself. Any way you slice it, the bug is in the system that's reporting the wrong condition, and adding a defensive check merely papers over an issue with additional code complexity.
Sure - your program can degrade gracefully. But that should be for informational / diagnostic purposes only. It doesn't change the fact that you're using a system that is not living up to its data contract.
To make an analogy pivoting on contracts: modern programming is often not a "rule of law" environment. If you try to pretend that it is when it's not, you're just going to get a lot of pain. And you can't fix everything by yourself.
At some point, the most efficient way to push back against bad code is by validating the contract at the boundary. Then, when that breaks, you have a lot more leverage to go around and demand fixing things.
Or, better yet, use systems that don't allow contracts to be so easily broken. Static typing is an example of that.
Getting the problem fixed is about culture as much as anything else.
If there is some legacy reason something cannot be fixed and has to keep returning bad data, then yes, there is 100% a reason to have two endpoints that do the same thing... usually prefixed with /v2/ or something
Whether or not it gets fixed is another issue entirely. If it doesn't get fixed, switch endpoints or switch jobs.