> Hide implementation detail and expose functionality through intention-revealing interfaces. Except "REST APIs" (what microservices expose almost always) don'

> Hide implementation detail and expose functionality through intention-revealing interfaces. Except "REST APIs" (what microservices expose almost always) don't reveal anything most of the time, wanting to hide internal state behind a beautiful and uniform facade essentially representing a two-tier model. For example, orders and order line items can't be added/deleted at will, but depending on whether the order has been processed or not, should expose a "cancel" action (with partial refund/with penalty for cancelling), etc. Sure you can hide that behind a DELETE method, or "reify" a "cancelled" status, but why? > Services are resilient to failures. In the case of "REST APIs", this means manually and labouriously attempting to reconcile state across multiple services in the client. Compare this with state changes though ordinary RPC, which can expose a meaningful state model, give contextual diagnostics/exceptions, and can have transaction context flowing with RPC calls.