Edition 0 Updated to asp. Net core 0

Communication styles 
There are many protocols and choices you can use for communication, depending on the 
communication type you want to use. If you’re using a synchronous request/response
-based 
communication mechanism, protocols such as HTTP and REST approaches are the most common, 
especially if y
ou’re publishing your services outside the Docker host or microservice cluster. If you’re 
communicating between services internally (within your Docker host or microservices cluster), you 
might also want to use binary format communication mechanisms (like WCF using TCP and binary 
format). Alternatively, you can use asynchronous, message-based communication mechanisms such as 
AMQP. 
There are also multiple message formats like JSON or XML, or even binary formats, which can be more 
efficient. If your chosen bi
nary format isn’t a standard, it’s probably not a good idea to publicly 
publish your services using that format. You could use a non-standard format for internal 
communication between your microservices. You might do this when communicating between 
microservices within your Docker host or microservice cluster (for example, Docker orchestrators), or 
for proprietary client applications that talk to the microservices. 
Request/response communication with HTTP and REST 
When a client uses request/response communication, it sends a request to a service, then the service 
processes the request and sends back a response. Request/response communication is especially well 
suited for querying data for a real-time UI (a live user interface) from client apps. Therefore, in a 
microservice architecture you’ll probably use this communication mechanism for most queries, as 
shown in Figure 4-16. 
Figure 4-16. Using HTTP request/response communication (synchronous or asynchronous) 

---

53 
CHAPTER 3 | Architecting container and microservice-based applications 
When a client uses request/response communication, it assumes that the response will arrive in a 
short time, typically less than a second, or a few seconds at most. For delayed responses, you need to 
implement asynchronous communication based on 
messaging patterns
 and 
messaging technologies
, 
which is a different approach that we explain in the next section. 
A popular architectural style for request/response communication is 
REST
. This approach is based on, 
and tightly coupled to, the 
HTTP
 protocol, embracing HTTP verbs like GET, POST, and PUT. REST is the 
most commonly used architectural communication approach when creating services. You can 
implement REST services when you develop ASP.NET Core Web API services. 
There’s additional value when using HTTP REST services as your interface definition language. For 
instance, if you use 
Swagger metadata
 to describe your service API, you can use tools that generate 
client stubs that can directly discover and consume your services.