Exposing your service via APIs

Microservices interact with each other and sometimes with the outside world over the network. A service exposes its capabilities through an API. I like to think of APIs as over-the-wire interfaces. Programming language interfaces use the syntax of the language they are written in (for example, Go's interface type). Modern network APIs also use some high-level representation. The foundation is UDP and TCP. However, microservices will typically expose their capabilities over web transports, such as HTTP (REST, GraphQL, SOAP), HTTP/2 (gRPC), or, in some cases, WebSockets. Some services may imitate other wire protocols, such as memcached, but this is useful in special situations. In 2019, there is really no reason to build your own custom protocol directly over TCP/UDP or use proprietary and language-specific protocols. Approaches such as Java RMI, .NET remoting, DCOM, and CORBA are better left in the past, unless you need to support some legacy code base.

There are two categories of microservices, which are as follows:

• Internal microservices are only accessible to other microservices running typically in the same network/cluster and those services can expose more specialized APIs because you're in control of both services and their clients (other services).
• External services are open to the world and often need to be consumed from web browsers or clients using multiple languages.

The benefit of using standard network APIs over standard language-agnostic transports is that it enables the polyglot promise of microservices. Each service may be implemented in its own programming language (for example, one service in Go and another in Python) and they may even migrate to a completely different language later (Rust, anyone?) without disruption, as all these services interact through the network API. We will examine later the polyglot approach and its trade-offs.