In Thinking about APIs I talked about the common problem of coupling between a client application and a server, via their shared knowledge of resource URLs: As I noted in that previous article, and as @Ivan pointed out in the comments, this is exactly analogous to a local function call, in that both the client and the server need to agree on the resource path (Connascence of Name)
A perrennial problem indeed, Kevin. The best way I know to bring this back before runtime is consumer driven contract testing (such as the Pact framework) - given you own both repos. If you allow the consumer to break the providers build Ive seen this facilitate TDD (red/green/refactor) across the API. Sure gets the collaboration dialled up when consumer and provider repos are shared across two distinct teams ;)
A perrennial problem indeed, Kevin. The best way I know to bring this back before runtime is consumer driven contract testing (such as the Pact framework) - given you own both repos. If you allow the consumer to break the providers build Ive seen this facilitate TDD (red/green/refactor) across the API. Sure gets the collaboration dialled up when consumer and provider repos are shared across two distinct teams ;)
I’m really enjoying this series. Thanks for sharing it.
For the topic of this article, Gary Bernhardt came up with a really interesting approach when writing www.executeprogram.com. You can read about that solution on their blog: https://www.executeprogram.com/blog/porting-to-typescript-solved-our-api-woes.