Handle Others’ Versions

Designing for version changes

When receiving requests or messages, our application has no control over the format. No matter how well the service’s expectations are defined, some non-serious person can pass us a bogus message. We’re lucky if the message is just missing some required fields. Right now, we’re just going to talk about how to design for version changes. (For a more thoroughly chilling discussion about interface definitions, see Integration Points). The same goes for calling out to other services. The other endpoint can start rejecting our requests at any time. After all, they may not observe the same safety rules we just described, so a new deployment could change the set of required parameters or apply new constraints. Always be defensive.

Loan application service

Let’s look at the loan application service again. As a reminder, from Table 1, Example Routes, we have some routes to collect a loan application and data about the borrower.

Now suppose a consumer sends a POST to the /applications route. The POST body represents the requester and the loan information. The details of what happens next vary ...