This post https://mastodon.social/@einarwh/114416251385900863 by @einarwh set me thinking. I might have another (anti-)pattern, the API Leach.
The API Leach comes about when a consumer is unable or unwilling to talk to the provider, but still needs the provided service. The consumer notices an interface exposed (but not advertised) by the provider and starts programming against it without the provider being aware of this. Maybe the interface is an internal API, or maybe it is not intended as an API at all, but as a UI for human users. Scraping web pages for data is one instance of this pattern.
Since the interface is not intended for consumption by external programs, the unwitting provider does not provide documentation, service levels, or support channels to the consumer team. The interface behavior is reverse engineered and may change at any time as the provider makes changes to the system. The interface may disappear without notice, too.
For the consumer team, this is a hard spot to be in. Reverse engineering an undocumented interface is inherently hard and error prone, and once they are done, the team must be ready to deal with unexpected behavior (and failure) at any time - be it due to misunderstanding during the reverse engineering phase or to technical or functional changes. In all probability, they won't have a test environment, either, and need to test against the production interface with production data, which can severely limit the range of tests that are viable.
The provider team is mostly unaffected, but may notice some oddities:
- unexpected usage patterns,
- increased error rate,
- increased load,
- strange support requests.
These may cause the provider team to notice that something is up.
And, of course, the producer may get yelled at after performing breaking changes if the consumer feels entitled enough.
Once the producer learns of the existence of the consumer, what happens next depends entirely on the power dynamics between the two parties. The interface may become an official API; the consumer may be shut out; both parties may negotiate a different API.
If at all possible, I would avoid this pattern and establish communication between the parties from the start.
#sociotechnicalsystems #apis #softwarearchitecture
