In 1998, a joke RFC created the '418 I'm a teapot' error. This talk explores the serious API design lessons we can learn from humorous internet standards.
#1about 3 minutes
The early design and limitations of HTTP 0.9
The initial HTTP protocol only had a single 'GET' verb and lacked status codes, making it difficult to programmatically distinguish between successful responses and errors.
#2about 3 minutes
Standardizing HTTP 1.0 with verbs and status codes
HTTP 1.0 formalized the protocol by adding multiple verbs like POST and PUT, standardized status codes for programmatic error handling, and headers like the misspelled 'Referer'.
#3about 4 minutes
The challenge of submitting complex form data over HTTP
To handle file uploads in web forms, developers reused email standards, forcing web servers to parse email-formatted requests sent over HTTP.
#4about 4 minutes
Satirizing protocol extensions with the coffee pot protocol
RFC 2324, an April Fools' standard, satirized inappropriate HTTP extensions by creating the Hyper Text Coffee Pot Control Protocol (HTCPCP) with a 'BREW' verb and the famous '418 I'm a teapot' error.
#5about 2 minutes
Extending the coffee pot protocol to support brewing tea
RFC 7168 extends the coffee pot protocol for tea, using the '300 Multiple Options' status code to allow a client to select from a list of available teas.
#6about 2 minutes
Evaluating REST APIs and proper use of status codes
While REST is a logical extension of HTTP's verbs for database operations, returning a 200 OK status with an error in the body undermines the purpose of status codes.
#7about 2 minutes
Exploring other notable April Fools' internet standards
Other humorous yet insightful April Fools' RFCs include specifying an 'evil bit' in TCP packets for firewalls and defining IP over Avian Carriers.
#8about 1 minute
Physical implementations of the coffee pot control protocol
While no fully compliant HTCPCP coffee pots exist due to the protocol's joke nature, many systems implement the '418 I'm a teapot' response and a hackathon project built a working device.
#9about 3 minutes
Q&A on IP over Avian Carriers and HTTP/2
The Q&A session addresses the practical limitations of IP over Avian Carriers, such as high latency and packet loss, and touches on the non-human-readable nature of HTTP/2.
Related jobs
Jobs that call for the skills explored in this talk.
Dev Digest 106 - DHH in HDAlright, first things first: we have an exclusive interview with David Heinemeier Hansson of Ruby on Rails and Hey fame for you all, so you can line that one up in another tab! WeAreDevelopers CPO Thomas Pamminger met with David Heinemeier Hansson, C...
Gerry Schneider
I have a stream! Why it’s definitely worth speaking at tech conferences.Giving talks at certain events is a longed-for goal for many developers. For a good reason: it is the perfect opportunity to share your expertise and passion for a specific topic, help others learn from your mistakes, drive awareness of your solution...
From learning to earning
Jobs that call for the skills explored in this talk.