How the web works: requests and responses

ASP.NET Core · Essentials · 10 min

Everything ASP.NET Core does is about receiving one kind of message and sending back another; this lesson names the parts.

Every time you open a website, or an app on your phone loads fresh data, two programs are talking. The one asking — your browser, or the app — is the client.

The program answering, on another computer, is the server. ASP.NET Core is Microsoft's toolkit for writing servers in C#.

They talk using HTTP, an agreed set of rules for the messages they exchange.

The client's message is a request; the server sends back exactly one response. One question, one answer — and the next request starts afresh.

A request says where it is going with a URL, a web address such as https://shop.example.com/products/42?color=red. After the site's name comes the path (/products/42), naming what you want, and an optional query string (?color=red) with extra details as name=value pairs.

A request also has an HTTP method, a verb saying what to do:

  • GET — fetch something (opening a page is a GET).
  • POST — send something new, such as a filled-in form.
  • PUT or PATCH — change something; DELETE — remove it.

Requests and responses carry headers: labelled extra details such as Content-Type: application/json, saying what kind of data is attached. Many also carry the data itself — a submitted form, say, travels in the request body.

Every response starts with a status code, a three-digit number saying how it went: 200 OK, 201 created, 400 your request was wrong, 404 not found, 500 the server broke. The first digit gives the family: 2xx success, 4xx the client's mistake, 5xx the server's fault.

Web pages — what a browser shows — are written in HTML. But when programs talk to each other, the data is usually JSON, a text format of names and values: {"id": 42, "name": "Lamp"}.

Programs offer each other operations through an API (application programming interface): a menu of things you can ask for, and how to ask. A web API is one you call over HTTP, usually exchanging JSON.

Each method-and-path a web API answers, like GET /products/42, is one endpoint. Most of this course is about building web APIs with ASP.NET Core.

Example

# curl is a command-line tool that sends one request and prints the response.
# -i shows the status line and headers too.
curl -i "https://api.github.com/repos/dotnet/aspnetcore"

# HTTP/2 200                                   <- status code: OK
# content-type: application/json; charset=utf-8  <- a header
#
# {                                            <- the body, in JSON
#   "id": 17620347,
#   "name": "aspnetcore",
#   "language": "C#",
#   ...
# }

# Another request: the GET method spelled out, plus a query string (?q=...):
curl -i -X GET "https://api.github.com/search/repositories?q=aspnetcore"

Remember

  • A client sends a request; the server sends back exactly one response
  • A request has a method (GET, POST...), a URL, headers and maybe a body
  • Status codes: 2xx success, 4xx the client's mistake, 5xx the server's fault
  • Web APIs exchange JSON; each method plus path is an endpoint

Watch out for

  • Thinking the server remembers earlier requests by itself — each request arrives on its own, with everything the server needs to answer it.

Check yourself

  1. An app asks for a product that doesn't exist. Which status code fits the response?
  2. In https://shop.example.com/search?term=lamp&page=2, what is the query string?

Sign in to answer, see the explanations, and get this lesson back as a quick review later.

Official docs: developer.mozilla.org/en-US/docs/Web/HTTP/Overview

Builds on

Nothing: this is a foundation.

Unlocks