▪ URL

The four main components of URLs are:

the protocol, domain, path, and query
It can be HTTP (without SSL) or HTTPS (with SSL)

For example:
https://www.example.com/category-A/subcategory-A1?searchTerm=Model+123

• path:
points to a specific file or other resource location

• Query:
The query string, also known as a fragment identifier, is frequently used for
internal searches and is commonly preceded by a question mark (?).

▪ request component:
API requests are made up of five basic components. These are:

1. Endpoints:
The endpoint is the URL that an API request is directed at.

ex
https://api.example.com/v2/lions
 ➢ The first is the actual destination of the resource that we’re trying to access.
This includes the domain of the server.
➢ the version of their API that we’re calling.
➢ endpoint for us to request this called /lions.

2. Methods
A method is an instruction that tells the server what we expect it to do with the
information that we’ve sent in our request.

▪ API protocol, uses standard HTTP methods. The most common of these
include:

• GET - for retrieving a data object.

• POST - for creating a new data object.
• PUT - for creating a new data object or altering an existing one.
• PATCH - for modifying an existing object.
• DELETE - for deleting existing objects.

ex

{“lions”:
{
“lionName”: “Franky”,
“age”: 16,
“adoptionDate”: 2016-02-02,
“favoriteFood”: “Steak”
}
}
 3. Parameters:
There are a few different types of parameters. These include:

• Path parameters - Extensions to the URL to select specific attributes that we

want to retrieve.
• Query parameters - For performing sort, filter, and pagination functions
within our request URL.
• Header parameters - Data that we store in our request headers. More on this
in a second.
• Request body parameters - Attributes that we place in our request body in
order to add or modify data objects.

4. Headers

This is useful for a number of reasons, including:

• Adding authentication details to prove that we are permitted to take
whatever action we’re requesting.
• Storing cookies.
• Configuring whether and how we want our request and response to be
cached.
 • Giving information about how our request is formatted and the type of
response we expect.

What are common API request headers?

There are many possible headers, but these are some common examples:

• Accept. Tells the API server which format you expect to receive back, e.g.
JSON or XML.
• Authorization. Provides authentication details, such as an API key or user
credentials.
• Content-type. Specifies the type of data being sent to the server in the
request body
• Cache-Control. Specifies whether and how a response should be cached.
• User-Agent. Identifies the client making the request.

5. Request bodies
Finally, we have the body of our request. This is where we store any data objects
and attributes that we want to send in our request - mostly within PUT and
PATCH, and POST requests.
 ▪ Responce component
The next component of an API that we need to get our heads around is the
response. This is what’s sent from the server back to the client after a request is
made.

This provides three key roles:

Outlining whether or not the request action was successful - and if not, why.
• Providing extra information around authentication, cookies, and caching.
• Passing data back to the client.
• Each of these has its own distinct section.

➢ status code
• 200 - The request was successful.
• 201 - The request succeeded and a new data object was created.
• 303 - The response can be found at a different location.(redirection)
• 400 - The request was bad and the server couldn’t understand it - likely due
to a syntax issue.
• 401 - The response was not authorized.
• 404 - The requested response wasn’t found.
• 408 - Request timeout.
• 500 - Internal server error.
• 501 - The server doesn’t support the requested method.
• 504 - The server is acting as a gateway and timed out trying to retrieve the
requested resources.
 • Response headers
The response can also include header parameters. These work in exactly the same
way as they do within an API request - to provide context to the information
included in the response itself.

Most of the time, response headers are used to do some combination of three
things:

• Sending cookies to the client, to be stored for user management purposes.

• Stipulating which additional authentication information is required.
• Giving information about the format of the response body.

▪ Cookies:

What is Cookie?
HTTP Сookies are small pieces of text data sent by a website and stored on a user's
computer by a web browser.

The data stored in the cookie is created by the server when it processes a request
from the client.
This data is tagged with an identifier that is unique to you and your computer.

HTTP Cookies Header Syntax

Following is the syntax for the Cookie header:

Cookie: [cookie-name=value]
 • Why use Cookies?
Cookies are mainly used for three purposes:

• Session management: Logins, passwords, or whatever the server needs to

remember
• Personalization: Custom settings, themes, and other settings
• Tracking: Recording and analysis of user behavior

Cons of Cookies:
• Cookies are always stored in the text format files and it can raise the
security risks such as cookie stealing, sensitive data exposure etc.

• Privacy: Whenever the user uses the browser to surf the internet, all the
cookies enabled sites will be able to track all the user activities.

• All the browsers have a feature to disable the cookies but, if users disable
the cookies, then most of the websites won’t work properly.
Types of Cookies:
• Session Cookies:
They are stored for a single session and are deleted when the current browser
session ends.
• Persistent Cookies:
Unlike session cookies, persistent cookies are not deleted when the session ends.
Instead, each persistent cookie has a pre-determined expiration date which can be a
few minutes, days, or even months after creation.
• Authentication Cookies:
Cookies are commonly used for authentication. In cookie-based authentication,
they identify the users and ensure that the correct user session sends sensitive
information.
 • Tracking Cookies
Tracking services record users' behavior on one or more websites and store it in
tracking cookies. Then, when the user visits such a website again, these cookies are
sent to the tracking service for analysis.
• Third Party and First-Party Cookies:
First-party cookies belong to the same domain as the one the user visits. In
comparison, third-party cookies belong to other domains and are used for tracking
purposes.
Parameter for Cookies:
Cookies have six parameters that can be passed to them:

• Name of the cookie – Determines the name of the cookie.

• Value of the cookie – Determines the value of the cookie.
• Expiration date of the cookie – determines how long the cookie will remain
active in your browser.
• Valid path for the cookie – This sets the URL path in which the cookie is
valid. Web pages or websites outside to the path of cookie cannot use the
cookie.
• Valid domain for the cookie – This takes the path parameter one step farther.
This makes the cookie accessible to pages on any of the servers when a site
uses multiple servers in a domain.
• Need for a secure connection – It specifies that a cookie can only be used
under a secure server condition, such as a site using SSL.

▪ Secure, HttpOnly, SameSite HTTP Cookies Attributes:

HttpOnly:
HttpOnly attribute focus is to prevent access to cookie values via JavaScript,
mitigation against Cross-site scripting (XSS) attacks.
SameSite:
Before the SameSite mechanism was introduced, browsers sent cookies in every
request to the domain that issued them, even if the request was triggered by an
unrelated third-party website. SameSite works by enabling browsers and
website owners to limit which cross-site requests, if any, should include specific
cookies. This can help to reduce users' exposure to CSRF attacks, which induce
the victim's browser to issue a request that triggers a harmful action on the
vulnerable website. As these requests typically require a cookie associated with
the victim's authenticated session, the attack will fail if the browser doesn't
include this.

All major browsers currently support the following SameSite restriction levels:
• Strict.
• Lax.
• None.

▪ Strict:
If a cookie is set with the SameSite=Strict attribute, browsers will not send it in
any cross-site requests. In simple terms, this means that if the target site for the
request does not match the site currently shown in the browser's address bar, it
will not include the cookie.
This is recommended when setting cookies that enable the bearer to modify
data or perform other sensitive actions, such as accessing specific pages that are
only available to authenticated users.

▪ None:
If a cookie is set with the SameSite=None attribute, this effectively disables
SameSite restrictions altogether, regardless of the browser. As a result,
browsers will send this cookie in all requests to the site that issued it, even
those that were triggered by completely unrelated third-party sites.

With the exception of Chrome, this is the default behavior used by major
browsers if no SameSite attribute is provided when setting the cookie.

There are legitimate reasons for disabling SameSite, such as when the
cookie is intended to be used from a third-party context and doesn't grant the
 bearer access to any sensitive data or functionality. Tracking cookies are a
typical example.

▪ Lax
Cookies with Lax SameSite restrictions aren't normally sent in any cross-site
POST requests, but there are some exceptions.

As mentioned earlier, if a website doesn't include a SameSite attribute when

setting a cookie, Chrome automatically applies Lax restrictions by default.
However, to avoid breaking single sign-on (SSO) mechanisms, it doesn't
actually enforce these restrictions for the first 120 seconds on top-level
POST requests. As a result, there is a two-minute window in which users
may be susceptible to cross-site attacks.

▪ Secure:
The Secure flag specifies that a cookie may only be transmitted using
HTTPS connections (SSL/TLS encryption) and never sent in clear text. The
Secure attribute is meant to protect against man-in-the-middle (MITM)
attacks. Note that this flag only protects the confidentiality of the cookie, not
its integrity.