3 ms·
There's a variant of this in $enterprise-dayjob: production system Foo is a service exposing a FooAPI with a spec documented in some machine readable format (S
by shoo 5y ago
There's a variant of this in $enterprise-dayjob: production system Foo is a service exposing a FooAPI with a spec documented in some machine readable format (SOAP ; Swagger/OpenAPI ; gRPC ). You don't need to infer the spec, you just get a copy of the spec in a machine readable format. You code generate a FooAPI client from the API spec, maybe you rig your API client to fail if it cannot decode a message with respect to the spec (it might do this by default if your code generator is any good). Maybe your new thing-with-a-FooAPI-client goes into production and you find out, lo and behold, the production FooAPI implementation doesn't honour its own spec, and encodes its data in some wacky way 5% of the time.
One stupid solution to this, that I would love to deploy, would be a circuit-breaker to detect API implementation defects. Similarly to how a circuit-breaker attempts to infer if a service is down/overloaded and temporarily disable the integration, an API-spec circuit breaker could be deployed with a copy of the API spec the external service is meant to be serving, and it could infer if that service doesn't actually implement the API spec. If it detected a counterexample from a message sent by the external service, it could disable the integration for an appropriate backoff retry interval to give the team maintaining the service enough time to align their spec or implementation (sleep 3 months to give the portfolio an opportunity to prioritise a fix; retry; sleep another three months... ).
Less stupidly, a lame but pragmatic solution can be to figure out the absolute minimal subset of the external API your use case needs in order to function. If an external service publishes an API spec with a huge service area [+], but you only need to use 1% of it, you might be advised to prune a copy of that API spec down that only focuses on the 1% you need. Validate that part of the message. Then if the external service does something weird in parts of the response you don't care about, you can ignore it instead of rejecting the entire payload.
[+] "service area" was a mistake, but it seems appropriate. maybe i need a circuit breaker between my brain and the keyboard.