Like so much of programming, HTTP (Hypertext Transfer Protocol) is profoundly simple, yet complex at the same time. In setting up a Sinatra app recently, I found myself getting errors related to how HTTP methods (get, put, post, patch, and delete) really work - and, more precisely, how HTTP really works, so I did some research. Here is what I discovered.
HTTP is a set of standards for sending and receiving messages between independent systems; the client sends a request and the server sends a response. These messages are just a collection of strings - and that is crazy to me! How can a string, which I sometimes think of as the most "lowly" of the data types, have so much power? The power lies in how the string is used - in this case, within the rigidly structured protocol that is HTTP, which dictates that information be passed as strings in a particular format.
Both messages - request and response - have a similar structure, consisting of a header and a body. The content is a series of strings that the browser (in our case) interprets as various kinds of media (text, pictures, audio, etc.). But what is really exchanged is a representation of that media (called a resource in HTTP and REST terms). In this Tuts guide, Ludovico Fisher eloquently explains that "We say that the request and response contain a representation of the resource. By representation, we mean information, in a certain format, about the state of the resource or how that state should be in the future. Both the header and the body [of the message] are pieces of the representation."
Often HTTP is described as an interaction between a client (the requester) and a server (the responder). More wise words from Fisher (see the caption below the picture) alerted me to a nuance in HTTP that I hadn't noticed before. HTTP is not just about the server and the client - there is a third party. It's me! And you, and all the other developers - "guardians of the REST" - out there.
Yesterday, I met Rails and even though I have only seen a tiny bit of what it can do, it's already pretty amazing!! And it would be meaningless (or at least have a VERY different meaning) without the guidance/stability/foundation of HTTP...which itself relies on a series of strings. From the outside, technology can seem divorced from humanity but this revelation about the not-always-mentioned, yet ever-present third party highlights the harmony between man and machine. Strings mean nothing to a computer - that is, until we programmer/guardians give them instructions for how to interpret those characters and assign actions for them.
HTTP is a set of standards for sending and receiving messages between independent systems; the client sends a request and the server sends a response. These messages are just a collection of strings - and that is crazy to me! How can a string, which I sometimes think of as the most "lowly" of the data types, have so much power? The power lies in how the string is used - in this case, within the rigidly structured protocol that is HTTP, which dictates that information be passed as strings in a particular format.
Both messages - request and response - have a similar structure, consisting of a header and a body. The content is a series of strings that the browser (in our case) interprets as various kinds of media (text, pictures, audio, etc.). But what is really exchanged is a representation of that media (called a resource in HTTP and REST terms). In this Tuts guide, Ludovico Fisher eloquently explains that "We say that the request and response contain a representation of the resource. By representation, we mean information, in a certain format, about the state of the resource or how that state should be in the future. Both the header and the body [of the message] are pieces of the representation."
Often HTTP is described as an interaction between a client (the requester) and a server (the responder). More wise words from Fisher (see the caption below the picture) alerted me to a nuance in HTTP that I hadn't noticed before. HTTP is not just about the server and the client - there is a third party. It's me! And you, and all the other developers - "guardians of the REST" - out there.
Yesterday, I met Rails and even though I have only seen a tiny bit of what it can do, it's already pretty amazing!! And it would be meaningless (or at least have a VERY different meaning) without the guidance/stability/foundation of HTTP...which itself relies on a series of strings. From the outside, technology can seem divorced from humanity but this revelation about the not-always-mentioned, yet ever-present third party highlights the harmony between man and machine. Strings mean nothing to a computer - that is, until we programmer/guardians give them instructions for how to interpret those characters and assign actions for them.
Remember: it's you, the programmer, who ultimately decides what happens when a certain HTTP method is used. There is nothing inherent to HTTP implementations that will automatically cause resources to be created, listed, deleted, or updated. You must be careful to apply the HTTP protocol correctly and enforce these semantics yourself.
I'm trying to avoid the Spider-Man great power/great responsibility quip....so I'll just allude to it instead! All of this is to say that I am eager to discover more of the potential within this programmer/guardian role and to see what benefits I can bring to technology and humanity through this medium. Happy Friday, fellow guardians!!
