feat(curriculum): add rest api and web services theory (#65634)

Co-authored-by: Zaira <33151350+zairahira@users.noreply.github.com>
2026-05-28 18:26:54 +00:00 · 2026-03-03 09:29:48 +01:00
parent dcddc3ecc3
commit 3250669a2b
6 changed files with 578 additions and 1 deletions
@@ -4665,6 +4665,12 @@
          "Learn the fundamentals of how web communication works through the HTTP request-response model, explore different types of web assets and responses, and understand how forms handle data submission using various HTTP methods."
        ]
      },
+      "lecture-understanding-rest-api-and-web-services": {
+        "title": "Understanding the REST API and Web Services",
+        "intro": [
+          "In these lessons, you will learn about REST APIs and web services, and how they allow different applications to communicate with each other over the internet."
+        ]
+      },
      "lecture-introduction-to-npm": {
        "title": "Introduction to npm",
        "intro": [
@@ -0,0 +1,199 @@
+---
+id: 697f1bf725c3210ceab3c440
+title: How Do Web Services Work?
+challengeType: 19
+dashedName: how-do-web-services-work
+---
+
+# --description--
+
+Web services and REST APIs power most of the apps and websites you use every day. They allow different applications to communicate with each other and share data over a network, most commonly the internet.
+
+An API (Application Programming Interface) is a general way for software to communicate with other software. A web service is a specific type of API that uses web technologies, such as HTTP, to exchange data over a network, usually the internet. Because of this, every web service is an API—but not every API is a web service. REST APIs are a common type of web service that follow a specific set of rules for how data is requested and returned.
+
+This lesson will focus on what web services are at a high level, and the next one will go into more details about how REST APIs work.
+
+You can think of a web service as a software-to-software bridge. It has no user interface and is not meant to be used directly. Instead, it is focused entirely on exchanging data between applications.
+
+For any system to be considered a web service, it must have the following characteristics:
+
+* **Runs on a server**: a web service must be hosted online like a website, but instead of pages that users can see, it exposes data or some functionality
+    
+* **Machine-to-machine communication**: a web service is not made for humans to view directly, but for mobile apps and web apps to consume, so they can expose some data or functionality that the user can finally view
+    
+* **Language-agnostic**: a web service can be written in any language such as Java or C#, and any app should be able to interact with it, even if it's written in a different language
+    
+* **Platform-agnostic**: it doesn't matter which platform the machines run on. For example, a web service running on Linux should not prevent a device running Windows from communicating with it
+    
+* **Use standard web protocols**: a web service should typically use HTTP/HTTPS to transfer data over the internet, FTP for file transfer, and SMTP for email
+    
+
+**REST** and **SOAP** are two of the most well-known types of web services, although other approaches exist, such as **XML-RPC**.
+
+**REST**, which stands for **Representational State Transfer**, is by far the most widely used today. Most modern applications rely on RESTful web services because they are simple, flexible, and work naturally with the web.
+
+REST APIs expose resources, which are usually represented by URL paths such as `/users` or `/users/20`. When a client requests a resource, the server returns a representation of that resource. This representation is often in JSON, but it can also be in formats like XML or even plain text.
+
+Clients can specify the format they want by using HTTP headers, such as the `Accept` header. For example, a client can request a JSON response by setting the appropriate `Accept` value.
+
+```bash
+Accept: application/json
+```
+
+And you can specify you want XML this way:
+
+```bash
+Accept: application/xml
+```
+
+The resource you get back can look like this if it is JSON:
+
+```json
+{
+  "id": 20,
+  "name": "John Doe",
+  "email": "john@example.com",
+  "role": "admin",
+  "createdAt": "2025-09-22T10:30:00Z"
+}
+```
+
+And this, if it is XML:
+
+```xml
+<user>
+  <id>20</id>
+  <name>John Doe</name>
+  <email>john@example.com</email>
+  <role>admin</role>
+  <createdAt>2025-09-22T10:30:00Z</createdAt>
+</user>
+```
+
+SOAP stands for **Simple Object Access Protocol**. It only uses XML data format, and it is the most common in enterprise-level systems that need more strict standards and security.
+
+Here's what SOAP data could look like:
+
+```xml
+<soapenv:Envelope xmlns:soapenv="http://schemas.xmlsoap.org/soap/envelope/">
+   <soapenv:Body>
+      <getUser>
+         <userId>20</userId>
+      </getUser>
+   </soapenv:Body>
+</soapenv:Envelope>
+```
+
+XML-RPC uses XML to encode its requests and responses. This makes it lightweight but less flexible than REST. 
+
+As for UDDI, it is not a data exchange service but an XML-based directory where businesses can list, discover, and describe their available web services.
+
+# --questions--
+
+## --text--
+
+What does **SOAP** stand for?
+
+## --answers--
+
+Structured Object Authorization Process
+
+### --feedback--
+
+Think of SOAP as a protocol that uses XML for exchanging structured data over a network.
+
+---
+
+Server-Oriented API Protocol
+
+### --feedback--
+
+Think of SOAP as a protocol that uses XML for exchanging structured data over a network.
+
+---
+
+Simple Object Access Protocol
+
+---
+
+Service-Oriented Application Procedure
+
+### --feedback--
+
+Think of SOAP as a protocol that uses XML for exchanging structured data over a network.
+
+## --video-solution--
+
+3
+
+## --text--
+
+What does REST expose that clients can interact with, such as `/users` or `/users/20`?
+
+## --answers--
+
+Functions
+
+### --feedback--
+
+Think of what `/users` represents — it's not code or a database, but the thing being represented.
+
+---
+
+Resources
+
+---
+
+Classes
+
+### --feedback--
+
+Think of what `/users` represents — it's not code or a database, but the thing being represented.
+
+---
+
+Endpoint
+
+### --feedback--
+
+Think of what `/users` represents — it's not code or a database, but the thing being represented.
+
+## --video-solution--
+
+2
+
+## --text--
+
+Which of the following is **not** a characteristic of a web service?
+
+## --answers--
+
+It must have a user interface for humans to interact with.
+
+---
+
+It runs on a server and exposes data or functionality.
+
+### --feedback--
+
+Think about the features that define web services.
+
+---
+
+It supports machine-to-machine communication.
+
+### --feedback--
+
+Think about the features that define web services.
+
+---
+
+It is language-agnostic and platform-agnostic.
+
+### --feedback--
+
+Think about the features that define web services.
+
+## --video-solution--
+
+1
@@ -0,0 +1,217 @@
+---
+id: 697f1c0bc18ebdcf3213a25e
+title: What Is The REST Architecture and How Does It Work?
+challengeType: 19
+dashedName: what-is-the-rest-architecture-and-how-does-it-work
+---
+
+# --description--
+
+**REST** stands for representational state transfer. Think of it as a set of guidelines that describe how web clients and servers should communicate with each other over the internet.
+
+In this lesson, you’ll learn what REST is, its key concepts, and how it works.
+
+REST defines a way for different systems to interact by using standard web technologies. With REST, clients such as web browsers, mobile apps, and APIs communicate with a server using common HTTP methods like `GET`, `POST`, `PUT`, `PATCH`, and `DELETE`, which we discussed in a previous lesson.
+
+Some core concepts of REST include **statelessness**, **resources**, **HTTP methods**, and **response or status codes**.
+
+**Statelessness** means that each request a client sends to the server is handled independently. The server does not remember previous requests. Because of this, every request must include all the information needed to process it. For example, if a user is authenticated, their authentication token must be sent with each request.
+
+In REST, everything is treated as a resource. A resource is a piece of data that can be accessed or modified. Each resource is identified by a URL, such as `/products` for all products, or `/products/1` for a specific product.
+
+Below is an overview of HTTP methods, status codes, and a step-by-step example of how the REST architecture works.
+
+## HTTP Methods
+
+HTTP methods define the action to perform on a resource:
+
+* `GET`: Retrieve a resource
+    
+* `POST`: Create a new resource
+    
+* `PUT / PATCH`: Update an existing resource
+    
+* `DELETE`: Remove a resource
+    
+
+## HTTP Status Codes
+
+After processing a request, the server responds with a **status code** that indicates the result:
+
+* `200` **(OK)**: The request was successful
+    
+* `201` **(Created)**: A new resource was created
+    
+* `400` **(Bad Request)**: The client sent invalid data
+    
+* `404` **(Not Found)**: The requested resource does not exist
+    
+* `500` **(Internal Server Error)**: An error occurred on the server
+    
+
+## How REST Works: A Step-by-Step Example
+
+### 1\. Client Sends a Request
+
+* The client sends an HTTP request using a method like `GET` or `POST`
+    
+* The request includes a URL identifying the resource
+    
+* It may also include headers, metadata, and a request body
+    
+
+### 2\. Server Receives the Request
+
+* The server validates the request format and authentication (if required)
+    
+* It identifies the target resource from the URL
+    
+* It determines the requested action based on the HTTP method
+    
+* It checks permissions and access control
+    
+
+### 3\. Server Performs the Action
+
+* `GET`: Retrieve the resource
+    
+* `POST`: Create a new resource
+    
+* `PUT / PATCH`: Update the resource
+    
+* `DELETE`: Remove the resource
+    
+* Any other necessary logic is executed
+    
+
+### 4\. Server Builds the Response
+
+* The server selects an appropriate status code (for example, `200`, `201`, or `404`)
+    
+* It formats the response data, usually as **JSON**
+    
+* It adds relevant headers such as `Content-Type` or `Cache-Control`
+    
+
+### 5\. Server Sends the Response
+
+* The response includes a status code, headers, and an optional body
+    
+* No client state is stored on the server (statelessness)
+    
+
+### 6\. Client Handles the Response
+
+* The client checks the status code to determine success or failure
+    
+* It processes any data returned by the server
+
+# --questions--
+
+## --text--
+
+What does statelessness mean in the REST architecture?
+
+## --answers--
+
+The server stores client data between requests.
+
+### --feedback--
+
+Think about how the server does not retain any memory of previous requests.
+
+---
+
+Each request is independent and contains all necessary information.
+
+---
+
+The client must store all server data locally.
+
+### --feedback--
+
+Think about how the server does not retain any memory of previous requests.
+
+---
+
+Requests do not require authentication tokens.
+
+### --feedback--
+
+Think about how the server does not retain any memory of previous requests.
+
+## --video-solution--
+
+2
+
+## --text--
+
+How does the REST architecture work step by step?
+
+## --answers--
+
+The server sends a request to the client, and the client processes it before sending a response.
+
+### --feedback--
+
+The client always initiates the request, and the server responds accordingly.
+
+---
+
+The client connects to the server, which continuously updates resources without new requests.
+
+### --feedback--
+
+The client always initiates the request, and the server responds accordingly.
+
+---
+
+The client sends a request, the server processes it, performs an operation, and sends a response.
+
+---
+
+The server automatically updates clients by pushing data without a request.
+
+### --feedback--
+
+The client always initiates the request, and the server responds accordingly.
+
+## --video-solution--
+
+3
+
+## --text--
+
+What does REST stand for?
+
+## --answers--
+
+Remote Execution and State Transfer 
+
+### --feedback--
+
+It's a standard for web communication between clients and servers.
+
+---
+
+Representational State Transfer
+
+---
+
+Rapid Encoding for Server Transactions
+
+### --feedback--
+
+It's a standard for web communication between clients and servers.
+
+---
+
+Reliable Endpoint Synchronization Technology
+
+### --feedback--
+
+It's a standard for web communication between clients and servers.
+
+## --video-solution--
+
+2
@@ -0,0 +1,138 @@
+---
+id: 697f1c0cc18ebdcf3213a25f
+title: What Are Microservices?
+challengeType: 19
+dashedName: what-are-microservices
+---
+
+# --description--
+
+In the past, most applications, whether large or small-scale, were built as monoliths. A monolith is one giant codebase that contains everything in the web app.
+
+This monolith system means the UI, database, and API all live in one codebase.
+
+Imagine an eCommerce store like Amazon, where the product pages, checkout system, payment processing, authentication and authorization, alongside the API and databases that power them all reside in the same codebase.
+
+The monolithic approach works well for small applications and early-stage startups. However, as an application grows and user demand increases, monoliths often become harder to maintain, slower to update, and difficult to scale. A small change in one area can require redeploying the entire system, and scaling one feature often means scaling the whole application.
+
+These challenges led to the rise of microservices, which is an architectural approach designed to address the limitations of monolithic systems.
+
+In a microservices architecture, a large application is broken into smaller, independent services. Each service is responsible for a specific business capability, such as products, orders, authentication, payments, and so on. These services often have their own codebases and may even manage their own databases, and can have entirely different teams working on them.
+
+The services communicate with each other through APIs or message-based systems, allowing them to work together as a single application.
+
+With this approach, both web and mobile applications are easier to maintain, update, and scale. For example, an e-commerce platform might have separate services for products, carts, users, orders, and payments. Each service can be built, deployed, and scaled independently without affecting the others.
+
+Microservices offer several advantages, including faster development, better fault isolation, and greater flexibility. Different services can use different programming languages or frameworks—for example, a search service might use Java, a product service might use Node.js, and an authentication service might use .NET.
+
+However, microservices also introduce new challenges. Debugging becomes more complex because issues can span multiple services. Deployment and infrastructure management are more complicated, and network overhead increases due to frequent communication between services.
+
+# --questions--
+
+## --text--
+
+What does **monolith** mean?
+
+## --answers--
+
+A system where UI, database, and API are split into separate services.
+
+### --feedback--
+
+Think of monolith as one big "all-in-one" application.
+
+---
+
+A single, large codebase containing the entire application.
+
+---
+
+A network of independent microservices working together.
+
+### --feedback--
+
+Think of monolith as one big "all-in-one" application.
+
+---
+
+A server dedicated to handling only database operations.
+
+### --feedback--
+
+Think of monolith as one big "all-in-one" application.
+
+## --video-solution--
+
+2
+
+## --text--
+
+What is a key characteristic of microservices?
+
+## --answers--
+
+All services share one codebase and one database.
+
+### --feedback--
+
+Think of microservices as small, independent apps that work together.
+
+---
+
+Services cannot be worked on by separate teams.
+
+### --feedback--
+
+Think of microservices as small, independent apps that work together.
+
+---
+
+The entire application is deployed as a single unit.
+
+### --feedback--
+
+Think of microservices as small, independent apps that work together.
+
+---
+
+Each service is independent, with its own codebase and sometimes its own database.
+
+## --video-solution--
+
+4
+
+## --text--
+
+Which of the following is a benefit of microservices?
+
+## --answers--
+
+All services must use the same programming language.
+
+### --feedback--
+
+Think of microservices as letting teams pick the right tools for each service.
+
+---
+
+A bug in one service brings down the entire system.  
+
+### --feedback--
+
+Think of microservices as letting teams pick the right tools for each service.
+
+---
+
+Different services can use different programming languages or frameworks.  
+
+---
+
+Development is slower because teams must work on one large codebase.
+
+### --feedback--
+
+Think of microservices as letting teams pick the right tools for each service.
+
+## --video-solution--
+
+3
@@ -0,0 +1,17 @@
+{
+  "name": "Understanding the REST API and Web Services",
+  "isUpcomingChange": true,
+  "dashedName": "lecture-understanding-rest-api-and-web-services",
+  "helpCategory": "Backend Development",
+  "blockLayout": "challenge-list",
+  "challengeOrder": [
+    { "id": "697f1bf725c3210ceab3c440", "title": "How Do Web Services Work?" },
+    {
+      "id": "697f1c0bc18ebdcf3213a25e",
+      "title": "What Is The REST Architecture and How Does It Work?"
+    },
+    { "id": "697f1c0cc18ebdcf3213a25f", "title": "What Are Microservices?" }
+  ],
+  "blockLabel": "lecture",
+  "usesMultifileEditor": true
+}
@@ -46,7 +46,7 @@
        {
          "dashedName": "introduction-to-express",
          "comingSoon": true,
-          "blocks": []
+          "blocks": ["lecture-understanding-rest-api-and-web-services"]
        },
        {
          "dashedName": "express-middleware",