Web Service Evolution
Patterns that mitigate the impact of breaking changes and enable web services and their clients to evolve gracefully.
Developers may select zero, one, or more of these patterns when designing a given service.
|Single Message Argument||How can a web service with an RPC API become less brittle and easily accommodate new parameters over time without breaking clients?|
|Dataset Amendment||How can a service augment the information it sends or receives while minimizing the probability of breaking changes?|
|Tolerant Reader||How can clients or services function properly when some of the content in the messages or media types they receive is unknown or when the data structures vary?|
|Consumer-Driven Contract||How can a web service API reflect its clients' needs while enabling evolution and avoiding breaking clients?|
The following sections relevant to web service evolution are only presented in the book.
|Breaking Changes||A breaking change is any service change that forces client developers to update their code or change configurations in 'lock-step' with the service deployment. Failure to change the client application at just the right time may cause it to crash. This section provides information to help you recognize the common causes of breaking changes for RESTful services and SOAP/WSDL services.|
|Versioning||How can clients be notified about service changes?|