microservices should be like little pals, all of them operating together like chummy relations who all work together to make a product / solution come together
SOAP，针对clientA could call serviceB with just the data it required这种情况下的协议变动，会很麻烦，client端部分也需要重新生成这种
REST by its nature is less tightly-coupled, so that clientA can call serviceB, not by a method name but by a URL, and by providing a more nebulous form of data. Definitions of contracts were not enforced per se, but instead were defined in consumable documentation (Swagger), and contract versions manageable by content negotiation, HATEOAS, and other means. 通过url而非method的方式，可以使得变更不那么麻烦
Tight-coupling means that changes to resources / contracts on microserviceA not only effect itself, but also any / all consumers of its data. If we update the contracts of microserviceA, we must (or at least should) redeploy all consumers of these contracts.
- define contract ownership at the consumer, not the publisher
- consider content negotiation as a contract version strategy
- avoid dns/url in favour of discovery services/ service register
- keep chattiness to minimum
- If direct communication is required, try to ensure that you minimise calls as best you can, through caching
针对api version部分，另一种观点
REST doesn’t provide for any specific versioning but the more commonly used approaches fall into three camps:
- putting it on the URI
- using a custom request header
- a adding it to the HTTP Accept header.
A coherent version strategy should address how you will manage change in your API whilst providing a stable contract to clients.
You can even take backwards compatibility a step further by adding features such as optional parameters and wildcard properties that anticipate future changes. This kind of “forwards compatibility” tends to produce a coarse contract that places a considerable burden of validation onto the client.