Recommended resources
The freely available resources this lesson will direct you to.
Hello, and welcome. This first module builds the IT foundations you will use later to reason about building-system data, cloud connections, and Building X applications. We will begin with the simplest useful picture: a client asks for something, and a server responds.
By the end of this lesson, you should be able to explain how that exchange lets someone use a software-as-a-service (SaaS) application without running its server-side software on their own computer. We will use a hypothetical building dashboard as our running example; it is an illustration, not a description of a specific Building X implementation.
The basic exchange: client and server
Imagine an operator opening a building dashboard in a browser. The browser is the client: it provides the interface the operator sees and initiates requests for pages or data. The server receives those requests, performs the necessary work, and sends responses. “Server” describes a role, not necessarily one physical computer; a service may use several computers behind the scenes.
The exchange is not a continuous stream of finished dashboard screens sent from the server. A browser might first request the page, then request its styling and scripts, and later request current values when the operator selects a building. Each request has a corresponding response.
Watch “What are HTTP requests?” from Codecademy for a short visual introduction to the messages exchanged between a browser and a server.
Watch the connection for the roles of HTTP, the browser, and the server. Then watch the response for an example of a successful reply and a “not found” reply. Focus on which side initiates the request and what comes back. We will refine one simplification in the video shortly: a connection does not always close after one response.
HTTP is the set of conventions used for these web requests and responses. It tells the participants how to express an action such as “get this resource,” and how to report the outcome. The network connection carries those messages. This distinction matters: a working connection makes communication possible, but the HTTP response tells us whether a particular request succeeded.
How an application produces what the client sees
A server can return a ready-made file, such as an image or a stylesheet. A useful SaaS application must also respond to requests whose answers depend on data. The server-side application might retrieve information from storage, apply its rules, and return a result appropriate to the request.
The following diagram shows one possible design: server-side code combines stored data with an HTML template. Trace the browser’s request to the web server, then the server-side application’s use of the database, and finally the response to the browser. The separate static-resource path supplies files such as CSS and JavaScript.
MDN Web Docs’ Introduction to the server side explains the distinction between a ready-made resource and a dynamically produced response. Read it with the diagram in mind.
Introduction to the server side
Read MDN Web Docs’ “Introduction to the server side” to connect the diagram’s browser, web server, application, and database to their respective jobs.
In “What is server-side website programming?”, begin where the text says browsers communicate with web servers. Read the exchange through the explanation of what a successful response can contain. In “Dynamic sites,” start with the definition of a dynamic website and read the dynamic-site explanation through the walkthrough beneath its diagram. Finally, in “Are server-side and client-side programming the same?”, read the role comparison. Focus on where presentation happens, where data is retrieved, and why the browser does not need to perform every task itself.
The diagram shows the server returning generated HTML, which the browser displays. That is one way to build a web application, but it is not the only one. An application can instead send a page and its JavaScript to the browser, then respond to later requests with data. The browser’s JavaScript uses that data to update a chart or a value on the page. In both designs, client-server communication supports the interaction: the client requests what it needs, and the server returns a result.
Keep the responsibilities separate. The browser handles much of the display and interaction. Server-side code can retrieve stored information, process a request, and decide what to return. A database, when one is used, is part of the server-side arrangement—not a screen that the browser directly opens.
What travels in a request and response?
A useful way to read a request is to identify what action is wanted and which resource it concerns. In HTTP, the method expresses the action. GET commonly asks for a resource. POST commonly sends data for the server to process. The path identifies the resource or operation within the service. Requests can also carry headers, and some carry a body containing data.
The response reports an outcome using a status code and may contain a body. A 200 OK response indicates success; a 404 Not Found response says the requested resource was not found. A successful body might be HTML, an image, or data for client-side code to use. A response arriving is therefore not the same as the requested operation succeeding.
MDN’s Overview of HTTP gives a compact reference for this message structure. You do not need to memorize every HTTP detail; concentrate on the parts you can identify when describing an application interaction.
Overview of HTTP - MDN Web Docs
Read these parts of MDN Web Docs’ “Overview of HTTP” to put precise names to the messages you have seen.
In “Components of HTTP-based systems,” under “Client: the user-agent,” read the page-loading account; notice that displaying one page can involve several requests. In “HTTP flow,” read the four steps, including the possibility of reusing a connection. In “HTTP Messages,” read the “Requests” and “Responses” subsections: request components and response components. Focus on method, path, status code, and body rather than the protocol-version details.
Now consider a hypothetical building dashboard. An operator opens its page, then selects a site. The browser might make a request resembling GET /sites/north/dashboard; the server could return a successful response containing the dashboard page. The browser might subsequently request data for a displayed temperature trend. If that data request succeeds, its response supplies values the browser can plot.
These are separate exchanges even though the operator experiences them as one activity. A page can appear while a chart remains empty if the page resources load but the later data request fails. Conversely, receiving data does not by itself guarantee that the browser displays it correctly. Separating request, server processing, response, and browser display makes the behavior much easier to explain—and eventually to troubleshoot.
Why this arrangement supports SaaS
Software as a service means the provider operates the application service, while customers access its functionality over a network. The client-server arrangement makes that division workable. A user’s browser supplies a local interface and sends requests; the remotely operated service supplies application behavior and data through responses. Multiple users can access the service from their own clients without each user installing and operating its server-side components.
For a building application, picture two different clients. An operator’s browser may request information to display. Separately, a building-side system may act as a client when it sends data to a cloud service. Both fit the broad client-server idea, although they serve different purposes. Later modules will examine the building-to-cloud path in detail; for now, do not assume that opening the dashboard is the same exchange as sending telemetry from a building.
The server-side application also gives the provider a place to apply rules about which information to return for a particular request. That does not mean every response contains all the data held by the service. We will study users and permissions separately; here, the important point is that a request is processed rather than automatically exposing storage to the client.
Finally, real deployments may put additional components between a client and the application, and an apparently single server may comprise several services. You can still use the basic model to ask productive questions: Who is the client in this exchange? What did it request? Which service handled it? What response came back? Those questions remain useful as the architecture becomes more detailed.
Key takeaways
Client-server communication supports SaaS through repeated requests and responses between a client and a remotely operated service. HTTP describes the web messages: a request specifies an action and resource; a response reports an outcome and may carry a page, file, or data. The browser presents and updates the interface, while server-side components can process requests and retrieve stored information. One visible dashboard interaction may involve several distinct exchanges.
Next, we will move below the application exchange and interpret an IP address, subnet mask, and default gateway in a sample network configuration—the information that helps a client reach services beyond its own local network.