{"id":"communication","title":"Communication","sections":[{"id":"overview","title":"Overview","html":"

\n \"Diagram\"\n
\n Source: OSI 7 layer model\n

","headings":[]},{"id":"hypertext-transfer-protocol-http","title":"Hypertext transfer protocol (HTTP)","html":"

Hypertext transfer protocol (HTTP)

\n

HTTP is a method for encoding and transporting data between a client and a server. It is a request/response protocol: clients issue requests and servers issue responses with relevant content and completion status info about the request. HTTP is self-contained, allowing requests and responses to flow through many intermediate routers and servers that perform load balancing, caching, encryption, and compression.

\n

A basic HTTP request consists of a verb (method) and a resource (endpoint). Below are common HTTP verbs:

\n\n\n\n\n\n\n\n\n\n\n\n\n\n\n\n\n\n\n\n\n\n\n\n\n\n\n\n\n\n\n\n\n\n\n\n\n\n\n\n\n\n\n\n\n\n\n\n
VerbDescriptionIdempotent*SafeCacheable
GETReads a resourceYesYesYes
POSTCreates a resource or trigger a process that handles dataNoNoYes if response contains freshness info
PUTCreates or replace a resourceYesNoNo
PATCHPartially updates a resourceNoNoYes if response contains freshness info
DELETEDeletes a resourceYesNoNo
\n

*Can be called many times without different outcomes.

\n

HTTP is an application layer protocol relying on lower-level protocols such as TCP and UDP.

\n

Source(s) and further reading: HTTP

\n","headings":[{"id":"hypertext-transfer-protocol-http","title":"Hypertext transfer protocol (HTTP)","depth":3},{"id":"sources-and-further-reading-http","title":"Source(s) and further reading: HTTP","depth":4}]},{"id":"transmission-control-protocol-tcp","title":"Transmission control protocol (TCP)","html":"

Transmission control protocol (TCP)

\n

\n \"Diagram\"\n
\n Source: How to make a multiplayer game\n

\n

TCP is a connection-oriented protocol over an IP network. Connection is established and terminated using a handshake. All packets sent are guaranteed to reach the destination in the original order and without corruption through:

\n\n

If the sender does not receive a correct response, it will resend the packets. If there are multiple timeouts, the connection is dropped. TCP also implements flow control and congestion control. These guarantees cause delays and generally result in less efficient transmission than UDP.

\n

To ensure high throughput, web servers can keep a large number of TCP connections open, resulting in high memory usage. It can be expensive to have a large number of open connections between web server threads and say, a memcached server. Connection pooling can help in addition to switching to UDP where applicable.

\n

TCP is useful for applications that require high reliability but are less time critical. Some examples include web servers, database info, SMTP, FTP, and SSH.

\n

Use TCP over UDP when:

\n","headings":[{"id":"transmission-control-protocol-tcp","title":"Transmission control protocol (TCP)","depth":3}]},{"id":"user-datagram-protocol-udp","title":"User datagram protocol (UDP)","html":"

User datagram protocol (UDP)

\n

\n \"Diagram\"\n
\n Source: How to make a multiplayer game\n

\n

UDP is connectionless. Datagrams (analogous to packets) are guaranteed only at the datagram level. Datagrams might reach their destination out of order or not at all. UDP does not support congestion control. Without the guarantees that TCP support, UDP is generally more efficient.

\n

UDP can broadcast, sending datagrams to all devices on the subnet. This is useful with DHCP because the client has not yet received an IP address, thus preventing a way for TCP to stream without the IP address.

\n

UDP is less reliable but works well in real time use cases such as VoIP, video chat, streaming, and realtime multiplayer games.

\n

Use UDP over TCP when:

\n\n

Source(s) and further reading: TCP and UDP

\n","headings":[{"id":"user-datagram-protocol-udp","title":"User datagram protocol (UDP)","depth":3},{"id":"sources-and-further-reading-tcp-and-udp","title":"Source(s) and further reading: TCP and UDP","depth":4}]},{"id":"remote-procedure-call-rpc","title":"Remote procedure call (RPC)","html":"

Remote procedure call (RPC)

\n

\n \"Diagram\"\n
\n Source: Crack the system design interview\n

\n

In an RPC, a client causes a procedure to execute on a different address space, usually a remote server. The procedure is coded as if it were a local procedure call, abstracting away the details of how to communicate with the server from the client program. Remote calls are usually slower and less reliable than local calls so it is helpful to distinguish RPC calls from local calls. Popular RPC frameworks include Protobuf, Thrift, and Avro.

\n

RPC is a request-response protocol:

\n\n

Sample RPC calls:

\n
GET /someoperation?data=anId\n\nPOST /anotheroperation\n{\n  \"data\":\"anId\";\n  \"anotherdata\": \"another value\"\n}
\n

RPC is focused on exposing behaviors. RPCs are often used for performance reasons with internal communications, as you can hand-craft native calls to better fit your use cases.

\n

Choose a native library (aka SDK) when:

\n\n

HTTP APIs following REST tend to be used more often for public APIs.

\n

Disadvantage(s): RPC

\n","headings":[{"id":"remote-procedure-call-rpc","title":"Remote procedure call (RPC)","depth":3},{"id":"disadvantages-rpc","title":"Disadvantage(s): RPC","depth":4}]},{"id":"representational-state-transfer-rest","title":"Representational state transfer (REST)","html":"

Representational state transfer (REST)

\n

REST is an architectural style enforcing a client/server model where the client acts on a set of resources managed by the server. The server provides a representation of resources and actions that can either manipulate or get a new representation of resources. All communication must be stateless and cacheable.

\n

There are four qualities of a RESTful interface:

\n\n

Sample REST calls:

\n
GET /someresources/anId\n\nPUT /someresources/anId\n{\"anotherdata\": \"another value\"}
\n

REST is focused on exposing data. It minimizes the coupling between client/server and is often used for public HTTP APIs. REST uses a more generic and uniform method of exposing resources through URIs, representation through headers, and actions through verbs such as GET, POST, PUT, DELETE, and PATCH. Being stateless, REST is great for horizontal scaling and partitioning.

\n

Disadvantage(s): REST

\n","headings":[{"id":"representational-state-transfer-rest","title":"Representational state transfer (REST)","depth":3},{"id":"disadvantages-rest","title":"Disadvantage(s): REST","depth":4}]},{"id":"rpc-and-rest-calls-comparison","title":"RPC and REST calls comparison","html":"

RPC and REST calls comparison

\n\n\n\n\n\n\n\n\n\n\n\n\n\n\n\n\n\n\n\n\n\n\n\n\n\n\n\n\n\n\n\n\n\n\n\n\n\n\n\n\n\n\n\n\n\n
OperationRPCREST
SignupPOST /signupPOST /persons
ResignPOST /resign
{
\"personid\": \"1234\"
}		DELETE /persons/1234
Read a personGET /readPerson?personid=1234GET /persons/1234
Read a person’s items listGET /readUsersItemsList?personid=1234GET /persons/1234/items
Add an item to a person’s itemsPOST /addItemToUsersItemsList
{
\"personid\": \"1234\";
\"itemid\": \"456\"
}		POST /persons/1234/items
{
\"itemid\": \"456\"
}
Update an itemPOST /modifyItem
{
\"itemid\": \"456\";
\"key\": \"value\"
}		PUT /items/456
{
\"key\": \"value\"
}
Delete an itemPOST /removeItem
{
\"itemid\": \"456\"
}		DELETE /items/456
\n

\n Source: Do you really know why you prefer REST over RPC\n

\n

Source(s) and further reading: REST and RPC

\n","headings":[{"id":"rpc-and-rest-calls-comparison","title":"RPC and REST calls comparison","depth":3},{"id":"sources-and-further-reading-rest-and-rpc","title":"Source(s) and further reading: REST and RPC","depth":4}]}],"sourceFiles":[]}