Understanding RFCs

REST APIs are built on top of the HTTP protocol, which is very well standardized. Since its inception, the HTTP protocol has been described through RFCs (Request For Comments). RFCs follow their own lifecycle, which has significantly slowed down as the number of Internet users has grown. Today, RFCs often end up “catching up” with common practice. RFCs are not standards in the ISO sense, but rather recommendations that most software organizations choose to follow. This distinction is also reflected in the way individual RFCs are labeled.

Exploring RFCs

The simplest way to look up an RFC is to use Google and enter the phrase together with the “RFC” suffix. For example, to find the RFC describing the HTTP header Accept:

From the search results, I recommend using the website tools.ietf.org.

Structure of an RFC Document

An RFC consists of a header, the RFC title, an abstract, a table of contents, and the main body of the text. Before analyzing an RFC, it is essential to check the header to confirm whether the document is still current. Below is an example of the header of RFC 7231, along with a description of its individual parts.

The right-hand side of the header also references corrections (Errata exist) and lists the authors.

For developers, it is crucial to check whether the RFC in question is already obsolete (Obsoleted by) or has been updated (Updated by). For example, in the sample shown, RFC 7231 has already been replaced by the newer RFC 9110. This happened fairly recently, in 2022.

The lifecycle of RFCs has evolved over the history of the IETF, and as a result, currently recognized standards are labeled in different ways:

All of the above lifecycle stages of an RFC should be respected by developers.