supotuco (29) [Avatar] Offline
Suppose we have the following situation. We have an api that returns a book `Title`. Chapter 5 suggests that we do not leak our domain primitives in the api so the title is returned as a JSON string to clients. Initially there was server side validation and client side validation to make sure a title does not have a blank value.

Suppose that the clients are mobile clients apps. This makes it difficult to update the client api if the server api changes. Now suppose you evolve the api to produce blank titles. This is not part of the api so it is valid since it is a string but it breaks old clients validating the title.

How can I maintain a stable client and validate data from data transfer objects?
404533 (5) [Avatar] Offline
This is definitely a concern all the time you have evolving APIs (which is a normal thing to have). The rate at which the API can evolve is limited by both the server side and the client side. As you correctly point out, some clients have a slower update rate than other - installed apps being among the slower, especially on iOS due to the time it takes to get an update through AppStore.

The most feasible way to handle this situation is to have the server API support several versions at the same time. Of course this is a burden for the server side developers, but the alternative is to have no evolution at all. Roll out support for new functionality on the server side API first, together with supporting old versions at the same time. Then update clients to start using the new API as well. Now it's time to monitor how many clients that have updated to the new version - and hopefully that proportion will rise over time. If you are lucky, all your clients will have upgraded within a reasonable period of time. Otherwise you need to put in reminders or incentives for them to update (perhaps taking about your nice new features?). Eventually there might be a few laggards that "refuse" to update, and you might simply have to stop supporting that version (obviously after due warning).

Thanks for pointing out a challenging situation for all API designers.