The envelope

The parcel that leaves Case’s phone at 10:00:00 has a shape, and the shape has a name.

It is a requestConcept · lights on your maprequestA structured message from client to server: here is what I want. One half of the web’s fundamental conversation. The server’s answer is the response., and everything Traversal will send back is a responseConcept · lights on your mapresponseThe server’s answer: here is the result, carried with a status code and usually some data. The other half of the conversation the request starts.. Ask, answer. The whole of the web is this one exchange repeated, a client asking and a server answering, billions of times an hour, until sheer repetition makes it look like something grander than it is. It is not grander.

The outside and the inside

Like any envelope, the request has writing on the outside. Which host this is for. What format the contents are in. What kind of thing the sender will accept back. Those labels are headerConcept · lights on your mapheaderLabelled metadata about a request or response: which host, what format, who is asking. Information about the message, as distinct from the message itself, which is the body. lines, and machines along the way read them the way a sorting office reads an address: quickly, incuriously, at unimaginable volume, and with no interest whatsoever in the birthday inside. Nobody at the sorting office opens the letter. Nobody needs to.

Inside is the bodyConcept · lights on your mapbodyThe primary content a request or response carries: the form being submitted, the page being returned. The headers only describe it.: the thing actually being sent. For Case’s parcel, that is the form. Name, date of birth, an optimistic guess at a finish time.

Reading and changing

There are two great kinds of asking. The difference between them will go on mattering long after this morning, in every meeting where somebody asks the deceptively small question of what happens if we do this twice.

When Molly opens the route page, her browser sends a GETConcept · lights on your mapGETThe HTTP method that retrieves information: loading a page, fetching a result. Meant to be safe to repeat, which is why a browser can reload one freely. Its counterpart for sending information is POST.. Reading. Nothing changes on Traversal’s side however many times she does it, and she does it a lot.

Case’s tap is the other kind. It is a POSTConcept · lights on your mapPOSTThe HTTP method that submits information for processing: a form, an order, a payment attempt. Repeating one may repeat the action, which is why browsers warn before resubmitting.: an ask that changes something. After it, the world is different by one lottery entry. Repeat a GET and nothing happens. Repeat a POST and something might happen twice, and that small might is a loose thread this act will leave hanging right up until its final scene, where it will matter more than anything else in the envelope. Remember it.

There are other methods for other jobs. PUTRecognition — just know it existsPUTThe HTTP method that commonly replaces a complete resource. A convention the server has to be built to support., PATCHRecognition — just know it existsPATCHThe HTTP method that commonly changes part of an existing resource, where PUT replaces the whole thing. and DELETERecognition — just know it existsDELETEThe HTTP method that asks for a resource to be removed. A convention, like PUT and PATCH, rather than something the protocol enforces. exist, and for now it is enough to know they do.

The envelope is addressed, labelled, and full. What the form looks like inside it deserves a scene of its own.