Rewrote resource change problem

Add a more broad view of the problem derived from changing entities and business understanding evolving. Also add common workarounds.

README.md

@@ -1523,7 +1523,8 @@ REST is focused on exposing data.  It minimizes the coupling between client/serv
 
 * With REST being resource oriented, it demands a solid understanding of the business, so hierarchy and relationships between resources can be properly modeled. A poorly designed API is hard to evolve and misleads future clients implementations.
 * Fetching complicated resources with nested hierarchies requires multiple round trips between the client and server to render single views, e.g. fetching content of a blog entry and the comments on that entry. For mobile applications operating in variable network conditions, these multiple roundtrips are highly undesirable. In this case, additional endpoints or query parameters logic must be implemented to return aggregated data and reduce latency.
-* Over time, more fields might be added to an API response and older clients will receive all new data fields, even those that they do not need, as a result, it bloats the payload size and leads to larger latencies.
+* Over time, fields might be added, changed or even removed from an API response. Breaking changes should be versioned, which adds the complexity of maintaning multiple endpoints or headers versioning logic. Addition of fields can also lead to unecessary data being sent, which leads to the necessity of implementing response filtering logic, usually through query paramenters.
+
 
 ### RPC and REST calls comparison