When you break your monolith up into microservices connected by exposed APIs, you expect these services to be decoupled and independently releasable. But too often they still aren’ t. Jose Luis Ordiales Coscia over at the Klarna blog explains how to fix this problem with the robustness principle.
When you break your monolith up into microservices connected by exposed APIs, you expect these services to be decoupled and independently releasable. But too often they still aren’ t. Jose Luis Ordiales Coscia over at the Klarna blog explains how to fix this problem with the robustness principle.
The robustness principle, also known as Postel’s law, states that you should be conservative with what you give and liberal with what you accept. In the context of APIs, this means your service should have very strict standards about what data gets shipped to clients and be very tolerant of what you get back from them. To illustrate why that might be a good idea, Jose gives the example of two services, one an address service, that stores addresses, and the other, its client, the user service that sends addresses to be saved. Imagine the initial setup is that the user service only sends a one line street address. The address team then decides to send city and zipcode data too. But the address service only expects a street name and so sends back a 400 error for the new requests from the user service. As a result, because the address service didn’ t follow the robustness principle and just ignore the new fields from the user service, the two services are immediately coupled.
For added robustness, Jose recommends versioning your API from day one. You never know when you might need to create changes that are not backwards-compatible. Without versioning, you’ ll create coupling issues. You can do versioning easily through the url or through the content-type in the HTTP header.
Jose also stresses that what goes for the service also goes for the API client. The client should also ignore fields in the response that are not relevant to him. The danger otherwise is that updates to irrelevant fields or new fields altogether might require code changes for the client.
Some developers think it’s fine if client requests fail because their requests don’ t match an exact pattern (e.g. contain extra fields) because the failures show the user how to use the API. But Jose thinks this kind of issue should be caught in consumer-driven contracts testing.
