| It has been suggested that RoS (computing) be merged into this article. (Discuss) Proposed since September 2015. |
Request–response, or request–reply, is one of the basic methods computers use to communicate with each other, in which the first computer sends a request for some data and the second computer responds to the request. Usually, there is a series of such interchanges until the complete message is sent; browsing a web page is an example of request–response communication. Request–response can be seen as a telephone call, in which someone is called and they answer the call.
Request–response is a message exchange pattern in which a requestor sends a request message to a replier system which receives and processes the request, ultimately returning a message in response. This is a simple, but powerful messaging pattern which allows two applications to have a two-way conversation with one another over a channel. This pattern is especially common in client–server architectures.
For simplicity, this pattern is typically implemented in a purely synchronous fashion, as in web service calls over HTTP, which holds a connection open and waits until the response is delivered or the timeout period expires. However, request–response may also be implemented asynchronously, with a response being returned at some unknown later time. This is often referred to as "sync over async", or "sync/async", and is common in enterprise application integration (EAI) implementations where slow aggregations, time-intensive functions, or human workflow must be performed before a response can be constructed and delivered.
In contrast, one-way computer communication, which is like the push-to-talk or "barge in" feature found on some phones and two-way radios, sends a message without waiting for a response. Sending an email is an example of one-way communication, and another example are fieldbus sensors, such as most CAN bus sensors, which periodically and autonomously send out their data, whether or not any other devices on the bus are listening for it. (Most of these systems use a "listen before talk" or other contention-based protocol so multiple sensors can transmit periodic updates without any pre-coordination.)
