Plain Text Protocols
If you haven't noticed already I really love plain text so I thought I would find some plain text protocols that are used in different software systems. The Redis Protocol specification states it best by describing its own protocol, but this applies to all of the plain text protocols I will cover.
- Simple to implement.
- Fast to parse.
- Human readable.
The next time you are building a software system and have to exchange data start with using a simple plain text protocol and then add in the complexity for optimization later. All of these protocols can be sent as plain text data over a TCP or UDP. They are easily inspected, small, and direct.
Graphite plaintext protocol
Starting off with the simplest one in the list is the Graphite plaintext protocol for delivering metrics into Graphite via Carbon.
The protocol:
<metics_path> <metics_value> <metrics_timestamp>
The example:
/cpu_load/core_0 0.08 1599009388
/cpu_load/core_1 0.07 1599009388
/cpu_load/core_2 0.07 1599009388
/cpu_load/core_3 0.05 1599009388
Influx Line Protocol
The next simplest one in the list is the Influx Line Protocol. While this is similar to Graphite it does add some additional metadata to its specification.
The protocol:
<measurement>[,<tag_set>...] <field_set>... <timestamp>
The example:
cpu,core=0 load=0.08 1599009388
cpu,core=1 load=0.07 1599009388
cpu,core=2 load=0.07 1599009388
cpu,core=3 load=0.05 1599009388
Redis Serialization Protocol (RESP)
Here is where things get more complex, but the same 3 characteristics from above apply still. Simplifying the protocol for the sake of brevity in this article we see that the protocol is a single line of text and the initial command dictates what argument data types are allowed after it.
The protocol:
COMMAND arguments...
The example:
GET key1
SET key2 100
HSET hash key1 value1
HGETALL hash
There is more to this particular protocol to denote strings, numbers, arrays, etc in a text format which is outlined in the official specification.
Hypertext Transfer Protocol (HTTP)
Yes, HTTP is just plain text. Since the protocol itself has lots of permutations of metadata lets just look at some examples of an HTTP request and response.
The request example:
GET /articles/plain-text-protocols/ HTTP/1.1
Host: blainsmith.com
Accept-Language: en-us
Accept-Encoding: gzip, deflate
The response example:
HTTP/1.1 200 OK
Accept-Ranges: bytes
Content-Length: 6262
Content-Type: text/html; charset=utf-8
Date: Wed, 02 Sep 2020 01:41:35 GMT
Last-Modified: Wed, 02 Sep 2020 01:37:33 GMT
<THE HTML OF THIS ARTICLE>
Your browser constructs the request when you visit http://blainsmith.com/articles/plain-text-protocols/ and parses the response when it comes back from the server. There are a lot more allowable headers, but the basics of this protocol are pretty straightforward.
Keep it simple
The world runs on these types of plain text protocol so don't reinvent the wheel if you find yourself building a software system and there is an existing protocol available. If there is an existing plain text protocol that you can adapt to your purposes then do that since there might be a library available already to serialize and deserialize the protocol so you don't have to write your own. If any of these protocols do not fit your needs and you need to write your own then keep it simple. If everyone's web browsers are using HTTP which has worked for decades there is no reason for you to create a complicated protocol unless your can prove the need to otherwise.