API Testing

What is FrontEnd?

Frontend is something that is visible to the user.

ex: In a web application, you can see the web elements like inputArea, radioButton, All elements are visible to the user.

What is BackEnding?

The backend is the code that is written by developers ,it could be data or database every thing is backend of an application and it is not visiable to user.

Ex:

When coming to the testing

In frontend manual testing is performed, with the help of frontend.
In Backend API testing fall in to Action .

NOTE: API is complete about backend.

What is WebApplication?

Any application which is accessable through browser is called as web application.

In client-server applications if we go for web application a browser act as a client.

server: process the request and give back the response to client.

What is Browser?

A browser is a stand-alone application that is used to access any webapplication over the network via URI.
The browser understand only HTML, CSS, JAVASCRIPT and hence it always create HTTP-request and interpret HTTP-response the given by the webserver.
The browser is the only way to access the web application.
The browser always sends and receive the request via HTTP (Hyper Text Transfer Protocol).

EX: Chrome, Brave , Firefox, Opera, Edge, etc.

What is WebServer?

Web- server as name implies it “server the Request to to browser” , it help both web-server and web-application to intract with each other.

🔹 Web Server

A Web Server is software (and sometimes hardware) that:

Stores, processes, and delivers web content (HTML, CSS, JavaScript, images, etc.) to clients (browsers).
Handles HTTP/HTTPS requests and responses.
Serves static content and can forward dynamic requests to an Application Server.

🔹 Functions of a Web Server

Accepts HTTP requests from browsers (clients).
Serves static files (HTML, CSS, JS, images, videos).
Can use plugins/CGI scripts to generate dynamic content.
Routes API or servlet requests to Application Server if needed.

🔹 Examples

Apache HTTP Server
Nginx
IIS (Internet Information Services)
LiteSpeed
Tomcat (acts as both Web + App server)

🔹 Web Server vs App Server (Quick Difference)

Feature	Web Server	Application Server
Purpose	Serves static content, handles HTTP requests	Runs business logic, processes dynamic content
Content	HTML, CSS, JS, images	Servlets, EJBs, APIs
Examples	Apache, Nginx, IIS	WebLogic, JBoss, Tomcat

✅ In short:
A Web Server is software that accepts client (browser) requests and serves static content or forwards dynamic requests to an Application Server for processing.

What is AppServer or WebApplication?

🔹 App Server (Application Server)

An Application Server is a software framework that provides an environment to run business logic (server-side code).
It handles complex operations like transactions, messaging, security, and database connectivity.
Examples: JBoss, WebSphere, WebLogic, GlassFish, Tomcat (partially).

👉 Think of it as:
“Where your core business logic lives and runs.”

🔹 Web Application

A Web Application is a software program that runs on a web server and can be accessed through a browser via the internet or intranet.
It usually contains frontend (UI) + backend logic + database.
Examples: Facebook, Gmail, Online Banking, Amazon.

👉 Think of it as:
“An actual application users interact with via a browser.”

🔹 Key Difference

Feature	App Server	Web Application
Definition	Platform to run business logic	Actual software used by end-users
Purpose	Provides environment for backend code	Provides functionality to users
Examples	JBoss, WebLogic, Tomcat	Gmail, Amazon, Netflix
User Access	Developers/Programs interact	End-users interact via browser

✅ In short:

App Server = The engine/environment that runs your backend code.
Web Application = The actual app (with UI + backend) users access via a browser.

Types of Web Resources?

🔹 Types of Web Resources

In web technology, a web resource is anything that can be identified and accessed on the web through a URL.

Common Types:

Static Resources → Fixed content that does not change.
- Examples: HTML files, CSS, JavaScript, images, videos, PDFs.
Dynamic Resources → Content generated at runtime by server-side code.
- Examples: JSP, Servlets, PHP scripts, ASP.NET pages, REST API responses.
Services (APIs / Endpoints) → Web services or APIs that expose data and operations.
- Examples: https://api.github.com/users, SOAP services.
Other Media Resources → Audio, video, documents, fonts delivered via the web.

👉 In short:
Web resources = Any file, document, or service that can be accessed over the web using a URL.

What is URL explain with syntax ?

🔹 What is URL?

URL (Uniform Resource Locator) is the address used to identify and access a resource on the internet.
It tells the browser where the resource is located and how to fetch it.

🔹 Syntax of a URL

protocol://hostname:port/path?query#fragment

🔹 Explanation of Parts

protocol → Communication method (e.g., http, https, ftp).
- Example: https
hostname (domain name / IP) → The server hosting the resource.
- Example: www.google.com
port → The communication endpoint (optional, defaults: 80 for HTTP, 443 for HTTPS).
- Example: :8080
path → Location of the resource on the server.
- Example: /products/list
query string → Extra parameters in key=value pairs (after ?).
- Example: ?id=10&sort=asc
fragment → A section inside the page (after #).
- Example: #section2

🔹 Example URL

https://www.amazon.in:443/laptops?brand=hp&sort=price#reviews

protocol → https
hostname → www.amazon.in
port → 443
path → /laptops
query → brand=hp&sort=price
fragment → reviews

✅ In short:

Web Resources = Any static/dynamic file or service accessible on the web.
URL = The complete web address used to locate and access those resources.

URL or WebURL is used to uniquely identify the specific web resources within the web application.
Every web application should have its unique adress in the form of url.

URL is the only way to access web applications vai browser.

Syntax of URL

protocol :// domainName:portNumber/resourcePath?queyString#fragmentId

What is protocol ?

When one application wants to communicate with other application, there need to be a common language that both applications understand each other ,Hence we use protocol.
The protocol is a common language where two applications exchange information with each other.
It is a set of rule and instructions.
The browser always sends a request and receives a response vai HHTP protocol hence it is called HHTP-request / HTTP-response,

Its optional information and case insensitive

Some other types of protocol are

HTTP
HTTPS
FTP
SMTP

What is domain name?

Used to uniquely identify the the specific computer / service within the network in which web application present.
A domain name might be a computer name ot IP-adress
It is mandotory information

Ex: www.amazon.com

What is port number ?

Used to uniquely identify the specific software/applicatiuon within the computer/system.
It is optional information in the webURL.
The below table specify the defect port number.

What is Resources path?

Used to uniqly identify the specific Web resources within the application server(webapplication).
EX:

What is Query String ?

It is one of the parameter passed in the URL which i used to specify / filter a condition.
Query String always begins with ” ? “.
Query String is always written in name = value pairs**.**
We can have any numbers of name = value pairs separated by “ & “ .

What is fragmentID?

Used to uniquely identify the specific fragment/ section within the webpage.
FragmentID should always begain with “ # “.
EX: #inbox, #Draft etc in gmail.

What are types of language ?

What is XML explain in details ?

What is XML entity reference ?

What is XML elements and attributes?

What are XML parser tools ?

What is XML prolog?

Difference between XML and HTML?

What is JSON?

Syntax of JSON?

What are the Datatypes of JSON?

What are the JSON parser tools?

Difference between XML and JSON?

What is Marshelling ?

What is UN-Marshelling?

What is Serealization?

What is De-Serealization?

What is an API?

What is WebService?

What is the Difference between API and WebService?

What is the Difference between FrontEnd Testing and BackEnd Testing?

What is API testing ?

What is WebService testing ?

What is SOAP?

What is SOAP Web Services?

What is .WSDL ?

🔹 WSDL (Web Services Description Language)

Definition (short):
WSDL is an XML-based language used to describe the functionality of a web service, including its methods, input/output parameters, data types, and endpoint URLs.

Key Points:

Used mainly with SOAP web services.
Acts like a contract between service provider and consumer.
Enables clients to generate code or requests automatically.

Example:

<definitions name="HelloService"
             targetNamespace="http://example.com/hello"
             xmlns="http://schemas.xmlsoap.org/wsdl/">
    <message name="SayHelloRequest">
        <part name="firstName" type="xsd:string"/>
    </message>
    <portType name="Hello_PortType">
        <operation name="sayHello">
            <input message="tns:SayHelloRequest"/>
            <output message="tns:SayHelloResponse"/>
        </operation>
    </portType>
</definitions>

✅ In short:
WSDL = XML file describing what a SOAP web service does, what parameters it accepts, and where it is located.

What is UDDI?

What is SOAP Web Services Testing?

What are the tools for SOAP Web Services available in market?

Disadvantages is SOAP ?

How SOAP expose the Web Services?

What is REST?

What is REST Web Services?

What is REST Web Services Testing?

What are the tools for REST Web Services available in the market?

What are the disadvantages is REST?

How REST expose the Web Services?

What is the Difference between SOAP and REST ?

Advantages of Web services ?

Explain HTTP structure ?

What is HTTP Request ?

What is HTTP Response ?

What is WEB URL ?

What is content type?

What is cookies?

What is form-data and raw-data?

What is status code ?

🔹 Status Code (in API / HTTP)

A status code is a three-digit number returned by a web server in the HTTP response to indicate the result of the client’s request.

It tells whether the request was successful, failed, redirected, or encountered an error.

🔹 Status Code Categories

1xx (Informational) → Request received, still processing.
- Example: 100 Continue
2xx (Success) → Request successful.
- Example: 200 OK, 201 Created
3xx (Redirection) → Further action needed (redirect).
- Example: 301 Moved Permanently, 302 Found
4xx (Client Error) → Request has an error from client side.
- Example: 400 Bad Request, 401 Unauthorized, 404 Not Found
5xx (Server Error) → Server failed to process valid request.
- Example: 500 Internal Server Error, 503 Service Unavailable

🔹 Example in RestAssured

given()
.when()
    .get("/users/2")
.then()
    .statusCode(200);   // Validating status code

✅ In short:
A status code is the server’s way of telling the client what happened with the request.

What is response time?

🔹 Response Time (in API Testing)

Response Time is the total time taken by the server to process a request and send back the response to the client.

It is usually measured in milliseconds (ms) or seconds (s).

🔹 Components of Response Time

Network latency → Time taken for request to travel from client → server.
Server processing time → Time server takes to process the request (database queries, business logic, etc.).
Response transfer time → Time taken for response to travel from server → client.

🔹 Why It Matters

Helps measure performance of APIs.
Ensures API meets SLA (Service Level Agreement) or business requirements.
Identifies performance bottlenecks.

🔹 Example in RestAssured

long responseTime = 
    given()
    .when()
        .get("/users/2")
    .time();

System.out.println("Response Time: " + responseTime + " ms");

✅ In short:
Response Time = Time taken from sending a request to receiving the full response.

What is actual data?

🔹 Actual Data (in Testing / API context)

Actual Data is the output or response returned by the system under test (SUT) when a test case is executed.

It is what you really get from the application or API during execution.

🔹 Example (API Testing)

Request: GET /users/1
Expected Data (Expected Result):

{
  "id": 1,
  "name": "John",
  "email": "john@example.com"
}

Actual Data (Actual Result):

{
  "id": 1,
  "name": "John",
  "email": "john@example.com"
}

Here, the Actual Data is the real response the API gives.

🔹 Why It’s Important

Used to compare with Expected Data.
If Actual = Expected → Test Pass.
If Actual ≠ Expected → Test Fail (defect found).

✅ In short:
Actual Data = The real output returned by the application when a test is run.

What are the pre-request for API testing?

🔹 Pre-requisites for API Testing

Basic Knowledge of APIs
- Understand REST, SOAP, HTTP methods (GET, POST, PUT, DELETE, PATCH).
- Know about request/response structure (headers, body, params).
API Documentation
- Have the API specification (Swagger, Postman collection, API contract).
- Know available endpoints, request format, and response format.
Access to API Environment
- Base URI (e.g., https://api.test.com).
- Test/staging environment where API is deployed.
Authentication & Authorization
- Valid credentials (API keys, tokens, OAuth, JWT, Basic Auth).
Test Data
- Input data required for API requests (IDs, payloads, params).
- Expected output data for validation.
API Testing Tools
- Tools like Postman, RestAssured, JMeter, SoapUI, or CURL.
Understanding of Status Codes
- Should know HTTP response codes (200, 201, 400, 401, 404, 500).
Network/Environment Setup
- Internet/VPN access (if API is restricted).
- Proxy/firewall permissions (if applicable).
Database Access (Optional)
- To validate if API response is consistent with backend DB.

✅ In short:
Before testing an API, you need documentation, environment details, authentication, test data, and tools to send/validate requests.

What are the limits of API usage?

🔹 Limits of API Usage

API usage limits are restrictions set by the provider to control how clients (users or applications) access the API.

They prevent abuse, server overload, and ensure fair usage.

🔹 Common Types of API Limits

Rate Limits
- Maximum number of requests allowed in a specific time period.
- Example: 1000 requests per hour.
Quota Limits
- Maximum number of requests allowed in a day, week, or month.
- Example: 50,000 requests per month.
Payload Size Limit
- Restriction on the size of request/response body.
- Example: Max 5MB per request.
Concurrent Request Limit
- Maximum number of API calls allowed at the same time.
- Example: 10 parallel requests.
Data Access Restrictions
- Limited fields/data can be fetched per call.
- Example: Only 100 records per API call.
Time-Out Limit
- APIs stop processing if the request takes too long.
- Example: 30 seconds timeout.
Authentication/Token Limitations
- API tokens/keys may have limited validity or scope.
- Example: Token valid for 1 hour.

🔹 Why Limits Exist

To protect server resources.
To ensure fair usage among all clients.
To prevent abuse/misuse like DoS attacks.

✅ In short:
API usage limits define how many requests you can send, how much data you can exchange, and under what conditions, to keep APIs reliable and secure.

How does API works?

An API (Application Programming Interface) acts as a middleman or an intermediary that allows two different software applications to communicate with each other. Instead of building every piece of functionality from scratch, applications can leverage APIs to access features or data from other applications.

Think of it like this:

Imagine you're in a restaurant (your application), and you want to order food (get data or a service). You don't go into the kitchen and cook it yourself. Instead, you look at the menu (the API documentation), tell the waiter (the API) what you want, and the waiter takes your order to the kitchen (the server or another application). The kitchen then prepares the food (processes the request) and the waiter brings it back to you (the API sends the response).

Here's a breakdown of how an API generally works, focusing on the most common scenario: Web APIs (like REST APIs) using HTTP:

Client Initiates a Request:
- A "client" (your web browser, a mobile app, another server, or even a command-line tool) needs information or wants to perform an action on a "server" (where the data or service resides).
- The client constructs an HTTP Request. This request includes:
  - Method: What kind of action (e.g., GET to retrieve, POST to create, PUT to update, DELETE to remove).
  - URL/Endpoint: The specific address of the resource or service it wants to interact with (e.g., https://api.example.com/users/123).
  - Headers: Additional information about the request (e.g., Authorization for authentication, Content-Type for the data format being sent, User-Agent to identify the client).
  - Body (optional): Data being sent to the server (e.g., JSON data for creating a new user in a POST request).
Request Sent Over the Internet:
- The client sends this HTTP request over the internet to the server hosting the API.
Server Receives and Processes the Request:
- The server's API receives the incoming request.
- It parses the request, looking at the method, URL, headers, and body.
- It authenticates and authorizes the client (checks if the client is who they say they are and if they have permission to perform that action on that resource). If not, it sends an error.
- It validates the request (e.g., Are all required parameters present? Is the data in the correct format?). If not, it sends an error.
- If valid and authorized, the API then executes the necessary logic. This might involve:
  - Querying a database to retrieve data.
  - Saving new data to a database.
  - Performing calculations.
  - Interacting with other internal services.
Server Sends an HTTP Response:
- Once the server has processed the request, it constructs an HTTP Response to send back to the client. This response includes:
  - Status Code: A numerical code indicating the outcome of the request (e.g., 200 OK for success, 404 Not Found if the resource doesn't exist, 500 Internal Server Error if something went wrong on the server).
  - Headers: Additional information about the response (e.g., Content-Type of the data being sent back, Date).
  - Body (optional): The actual data requested by the client (e.g., a JSON object containing user details) or a message indicating the result of an action (e.g., "User created successfully").
Client Receives and Processes the Response:
- The client receives the response.
- It interprets the status code to understand if the request was successful or if an error occurred.
- It parses the response body (if any) to extract the data or confirmation message.
- It then uses this data to update its user interface, perform further actions, or display information to the user.

Key principles that make APIs work efficiently:

Standardization: APIs often adhere to common standards (like HTTP, REST principles, JSON, XML) which makes them predictable and easier for different applications to understand and integrate with.
Contract: The API acts as a contract between the client and the server. The API documentation defines what requests the server expects and what responses it will send back.
Abstraction: APIs hide the complexity of the underlying system. The client doesn't need to know how the server stores data or performs its operations; it just needs to know what to ask for and what to expect back.
Statelessness (in REST): Each request from a client to a server contains all the information needed to understand the request. The server doesn't store any client context between requests. This makes APIs more scalable.

In essence, APIs provide a structured and standardized way for software components to interact, enabling modularity, reusability, and the creation of complex applications by combining capabilities from various sources.

What are the main type of API?

APIs (Application Programming Interfaces) can be categorized in a few ways, but the most common classifications are based on their access level (who can use them) and their architectural style/protocol (how they work).

Here are the main types:

By Access Level (Audience)

This classification focuses on the intended users of the API and the level of access granted.

Public APIs (Open APIs / External APIs):
- Description: These APIs are available for anyone to use, often with little to no restriction. They are designed to be easily consumable by external developers and the general public, encouraging innovation and integrations. While many are free, some may have usage limits or require registration and an API key.
- Examples: Google Maps API, Twitter API, OpenWeatherMap API.
- Use Case: Allowing third-party developers to build applications that leverage a company's data or services.
Partner APIs:
- Description: These APIs are shared externally, but only with specific, authorized business partners. Access is usually governed by a formal agreement or contract, and they often involve stricter security and access controls than public APIs.
- Examples: An e-commerce platform's API for shipping companies, a payment gateway API used by online stores (e.g., Stripe, PayPal).
- Use Case: Facilitating secure and controlled communication and data exchange between collaborating businesses.
Private APIs (Internal APIs):
- Description: These APIs are developed and used exclusively within an organization. They are not exposed to external users or third parties. Their primary purpose is to connect different internal systems, services, or teams, streamline internal processes, and enhance productivity.
- Examples: An API connecting a company's CRM system to its accounting software, an API for managing employee data within an HR system.
- Use Case: Enabling integration between various components of a company's own IT infrastructure, often supporting microservices architectures.
Composite APIs:
- Description: These APIs combine multiple data or service APIs into a single, unified interface. They allow developers to make a single request to receive data or perform actions that would otherwise require multiple individual API calls.
- Examples: A dashboard API that pulls user profile, order history, and payment information from three different internal services in one go.
- Use Case: Simplifying complex interactions, reducing network calls, and improving performance for applications that need data from various sources.

By Architectural Style/Protocol (How they work)

This classification relates to the underlying technology and communication patterns.

REST APIs (Representational State Transfer):
- Description: The most popular and widely used type of web API. REST is an architectural style that leverages standard HTTP methods (GET, POST, PUT, DELETE, PATCH) to interact with resources identified by URLs. They are stateless, flexible, and typically use JSON or XML for data exchange.
- Why popular: Simplicity, scalability, and compatibility with web standards.
- Use Case: Building modern web and mobile applications, microservices, and general data exchange over the internet.
SOAP APIs (Simple Object Access Protocol):
- Description: A protocol that uses XML to structure messages for web services. SOAP is more rigid, standardized, and often requires a WSDL (Web Services Description Language) file. It supports various transport protocols (HTTP, SMTP, TCP).
- Why used: Known for strong security features (WS-Security), ACID compliance, and formal contracts, often favored in enterprise-level applications, finance, and healthcare.
- Use Case: Enterprise systems, legacy integrations, applications requiring high security and transactional integrity.
GraphQL APIs:
- Description: A query language for APIs that allows clients to request exactly the data they need from the server, avoiding over-fetching or under-fetching of data. It operates over a single endpoint and is highly efficient.
- Why popular: Offers flexibility and efficiency in data retrieval, especially for complex applications with varying data needs.
- Use Case: Mobile applications, single-page applications, and scenarios where clients need highly specific data.
RPC APIs (Remote Procedure Call):
- Description: This type of API allows a program to execute a procedure (function or subroutine) in a different address space (typically on a remote server) as if it were a local procedure. Variations include XML-RPC (using XML) and JSON-RPC (using JSON).
- Why used: Simple for calling specific functions directly.
- Use Case: Scenarios where direct function invocation is preferred over resource manipulation, often in older systems or specialized microservices (like gRPC, which is a modern high-performance RPC framework using Protocol Buffers and HTTP/2).

Understanding these different types of APIs helps in designing, developing, and testing software effectively, as each type has its own strengths, weaknesses, and appropriate use cases.

What are some common protocol used in API testing ?

API testing involves interacting with Application Programming Interfaces (APIs) to ensure they are functioning correctly, securely, and efficiently. Several common protocols are used for this, each with its characteristics and use cases:

REST (Representational State Transfer):
- Description: REST is an architectural style, not a strict protocol, that uses standard HTTP methods (GET, POST, PUT, DELETE, PATCH) to perform operations on resources identified by URLs (endpoints). It's stateless, meaning each request from the client to the server contains all the information needed to understand the request.
- Data Formats: Primarily uses JSON (JavaScript Object Notation), but can also use XML, HTML, or plain text.
- Why it's common in testing: Its simplicity, widespread adoption, and reliance on standard HTTP make it very easy to test using tools like Postman, SoapUI, or even cURL. Testers can easily simulate requests and validate responses.
- Testing Focus: Verifying HTTP methods, status codes, response payloads (data, format), error handling, and resource manipulation.
SOAP (Simple Object Access Protocol):
- Description: SOAP is a protocol that uses XML to define the structure of messages for exchanging structured information in web services. It's more rigid and standardized than REST, often requiring a Web Services Description Language (WSDL) file to describe the service.
- Data Formats: Primarily XML.
- Why it's common in testing: Despite its complexity, SOAP is still widely used in enterprise environments, especially for legacy systems and applications requiring strict security and transactional integrity. Testing tools like SoapUI are specifically designed for SOAP APIs.
- Testing Focus: Validating XML request and response structures, ensuring operations defined in WSDL work as expected, handling security (WS-Security), and testing complex workflows.
GraphQL:
- Description: GraphQL is a query language for APIs and a runtime for fulfilling those queries with your existing data. Developed by Facebook, it allows clients to request exactly the data they need, no more and no less, by defining a schema.
- Data Formats: Primarily JSON for queries and responses.
- Why it's common in testing: Its flexibility and efficiency in data fetching make it popular for modern applications. Testing involves crafting specific queries and mutations (for data modification) and verifying the precise data received.
- Testing Focus: Validating query syntax, ensuring accurate data retrieval based on specific fields requested, testing mutations, and checking for proper error handling when queries are malformed or unauthorized.
RPC (Remote Procedure Call):
- Description: RPC is a protocol that allows a program on one computer to cause a procedure or function to execute on a different computer without the programmer explicitly coding the remote interaction. It's more about calling functions directly rather than manipulating resources.
- Variations: Includes XML-RPC (uses XML over HTTP) and JSON-RPC (uses JSON over HTTP).
- Why it's common in testing: While less common for general-purpose web APIs than REST, it's used in specific scenarios where direct function calls are more appropriate.
- Testing Focus: Verifying that specific remote procedures are executed correctly and that the returned results are as expected.
gRPC (Google Remote Procedure Call):
- Description: A modern, high-performance RPC framework developed by Google. It uses Protocol Buffers (Protobuf) for efficient serialization of structured data and HTTP/2 for transport, enabling faster communication and advanced features like streaming.
- Data Formats: Protocol Buffers.
- Why it's common in testing: Increasingly used in microservices architectures due to its performance benefits. Testing gRPC APIs often requires specialized tools and libraries that can handle Protobuf and HTTP/2.
- Testing Focus: Validating service methods, data serialization/deserialization, streaming behaviors (client-side, server-side, bidirectional), and error handling.

Key considerations in API testing regardless of protocol:

Functional Testing: Verifying that the API performs its intended functions correctly.
Performance Testing: Assessing the API's speed, responsiveness, and stability under various loads (e.g., load testing, stress testing).
Security Testing: Checking for vulnerabilities like authentication and authorization flaws, injection attacks, and data exposure.
Reliability Testing: Ensuring consistent behavior and error handling under different conditions.
Validation: Checking response status codes, data types, and the structure of the response body.
Error Handling: Testing how the API responds to invalid inputs, missing parameters, or server-side issues.

The choice of protocol for API testing heavily depends on the API itself, as testers must use tools and methods compatible with the API's chosen communication standard.

What are the components of an HTTP request?

An HTTP request is a message sent by a client (like your web browser) to a server to request a resource. It's made up of several key components:

Request Line: This is the first line of the HTTP request and contains three parts:
- Method: This indicates the action the client wants to perform on the resource. Common methods include:
  - GET: Retrieves data from the server.
  - POST: Submits data to be processed to a specified resource.
  - PUT: Replaces all current representations of the target resource with the request payload.
  - DELETE: Deletes the specified resource.
  - HEAD: Retrieves the headers only, without the body.
  - OPTIONS: Describes the communication options for the target resource.
- Path (or Request-URI): This specifies the particular resource the client is requesting on the server. For example, /index.html or /api/users.
- HTTP Version: This indicates the version of the HTTP protocol the client is using (e.g., HTTP/1.1, HTTP/2.0).
Headers (or Request Headers): These are lines following the request line that provide additional information about the request, the client, or the body of the request. They are in the format Header-Name: Header-Value. Some common headers include:
- Host: Specifies the domain name of the server (required for HTTP/1.1).
- User-Agent: Identifies the client software making the request (e.g., browser type and version).
- Accept: Indicates the media types (e.g., text/html, application/json) that the client is willing to accept in the response.
- Accept-Language: Specifies the preferred human language for the response.
- Accept-Encoding: Specifies the encoding methods the client understands (e.g., gzip, deflate).
- Content-Type: Indicates the media type of the request body (important for POST and PUT requests).
- Content-Length: The length of the request body in bytes.
- Cookie: Contains HTTP cookies previously sent by the server.
- Authorization: Contains credentials for authenticating a user agent with a server.
Blank Line: A blank line (CRLF - carriage return, line feed) separates the headers from the message body. This is crucial for the server to understand where the headers end and the body begins.
Message Body (or Request Body): This is an optional part of the request, used to send data to the server, primarily with POST and PUT methods. For example, when submitting a form, the form data would be in the request body. The format of the body is specified by the Content-Type header.

In summary, an HTTP request looks something like this:

GET /index.html HTTP/1.1
Host: www.example.com
User-Agent: Mozilla/5.0 (Windows NT 10.0; Win64; x64) AppleWebKit/537.36 (KHTML, like Gecko) Chrome/126.0.0.0 Safari/537.36
Accept: text/html,application/xhtml+xml,application/xml;q=0.9,image/webp,image/apng,*/*;q=0.8
Accept-Language: en-US,en;q=0.9

(Optional request body would go here)

What does HTTP methods do?

HTTP methods (also known as HTTP verbs) define the type of action a client wants to perform on a resource identified by a URL. They are a core part of how RESTful APIs are designed and interact with resources. Here are the most common ones and their primary functions:

GET:
- Purpose: Retrieves data from the server.
- Characteristics: Idempotent (multiple identical requests have the same effect as a single one) and safe (doesn't change server state).
- Usage: Fetching a webpage, getting a list of users, retrieving details of a specific product.
- Body: Typically no request body.
POST:
- Purpose: Sends data to the server to create a new resource or submit data for processing.
- Characteristics: Not idempotent (multiple identical requests can create multiple resources) and not safe.
- Usage: Submitting a form, creating a new user account, uploading a file.
- Body: Contains the data to be sent (e.g., JSON, form-data).
PUT:
- Purpose: Updates an existing resource or creates a new resource if it doesn't exist at the specified URL. It replaces the entire resource with the new data.
- Characteristics: Idempotent (putting the same resource multiple times has the same final state).
- Usage: Fully updating a user's profile, replacing a document.
- Body: Contains the complete new representation of the resource.
PATCH:
- Purpose: Applies partial modifications to an existing resource. It only sends the data that needs to be changed.
- Characteristics: Not necessarily idempotent (depends on the specific implementation, but often designed to be).
- Usage: Updating only a user's email address, incrementing a counter.
- Body: Contains only the fields to be modified.
DELETE:
- Purpose: Removes a specified resource from the server.
- Characteristics: Idempotent (deleting a resource multiple times has the same effect as a single one: the resource is gone).
- Usage: Deleting a user, removing a product from a database.
- Body: Typically no request body.
HEAD:
- Purpose: Similar to GET, but requests only the headers of the response, not the body.
- Characteristics: Idempotent and safe.
- Usage: Checking if a resource exists, verifying a file's size or modification date without downloading the entire content.
OPTIONS:
- Purpose: Describes the communication options for the target resource. It can be used to query the server about the HTTP methods supported by an endpoint.
- Characteristics: Idempotent and safe.
- Usage: Used in CORS (Cross-Origin Resource Sharing) preflight requests to check if an actual request is safe to send.