Each method serves a specific purpose to keep web communication clear, secure, and organized.

In this article, we will break down the most common HTTPS methods and explain how they function to make online interactions work smoothly.

Table of Contents

1. GET Method

2. POST Method

3. PUT Method

4. PATCH Method

5. DELETE Method

6. HEAD Method

7. OPTIONS Method

8. TRACE Method

9. CONNECT Method

10. Conclusion

GET Method

The GET method is one of the most common HTTP methods and is used to request data from a server. Think of it as asking for information without changing anything.

When you visit a webpage, your browser sends a GET request to the server asking for the content of the page. The server then responds with the data (such as HTML, images, or other files) that the browser displays.

One important thing about GET is that it doesn't make any changes to the data. It simply "reads" or retrieves the information. For example, when you browse through social media or search for products online, the app or website uses GET to display data without altering it.

Another key point is that GET requests send parameters in the URL itself. This means any data you're asking for is visible in the browser's address bar. For example, if you're searching for a product on an online store, the search term is included in the URL.

Example of a GET Request

Here’s a simple example of a GET request in JavaScript using the Fetch API:

fetch('https://api.example.com/products?category=shoes')
  .then(response => response.json())
  .then(data => console.log(data))
  .catch(error => console.error('Error:', error));

In this example, the GET request is made to the URL https://api.example.com/products with a query parameter category=shoes, asking the server to return products in the shoes category.

Use Cases of the GET Method

GET is mainly used to fetch information, and there are many common scenarios where it's applied:

1. Loading a Webpage: Every time you type a URL into your browser or click a link, you're making a GET request. The browser asks the server for the webpage, and the server sends back the content to display.

   • Example: GET /index.html HTTP/1.1

2. Fetching Data from APIs: When developers build applications, they often use APIs (Application Programming Interfaces) to get data from external servers. For instance, a weather app uses a GET request to fetch the current temperature from a weather API.

   • Example:

    fetch('https://api.weather.com/current?city=Lagos')
       .then(response => response.json())
       .then(data => console.log(data));

3. Search Queries: When you search for something on Google or other search engines, a GET request is made. The search term you entered is included in the URL, and the server returns a list of matching results.

   • Example: GET /search?q=JavaScript

4. Retrieving Files: Whether you're downloading an image, viewing a PDF, or playing a video, GET is used to fetch those files from a server.

   • Example: GET /files/image.jpg

Best Practices for GET Requests

To use GET requests effectively, it's important to follow some good practices to ensure smooth and secure data handling:

1. Use GET Only for Retrieving Data: GET requests are meant to fetch data, not to send sensitive information like passwords or personal data. Since the parameters in a GET request are included in the URL, anyone can see them. For example, if you're logging into a website, you shouldn't use GET to send your password, because it would show up in the URL.

   • Example of what not to do:

    fetch('https://example.com/login?username=john&password=secret');

2. Keep URLs Short and Clean: Since GET requests include data in the URL, long URLs can become problematic. There is also a limit to how much data can be included in a GET request URL (depending on the browser and server), so avoid putting too much information there. If you need to send a lot of data, consider using a POST request instead.

3. Enable Caching for Performance: GET requests are often cached by browsers, meaning the browser can store the response and reuse it without contacting the server again. This improves performance, especially for static content that doesn’t change often, like images or style sheets. To take advantage of this, ensure your server sends proper cache-control headers, so frequently requested data can be loaded faster.

   • Example of setting cache headers:

    Cache-Control: max-age=3600

4. Avoid Making GET Requests for Actions That Change Data: Since GET is a "safe" method, it should only be used for actions that don't modify data. If you want to create, update, or delete data, use methods like POST, PUT, or DELETE. For instance, if you accidentally use GET to delete a resource, someone could remove it just by clicking a link or refreshing the page, which is not safe.

   • Example of not using GET for deletion:

    GET /delete/user/123

5. Be Cautious with Sensitive Data: Since GET requests are part of the URL, they can be logged or saved in a browser’s history. Avoid sending sensitive information like passwords, credit card details, or private data in a GET request. Always use methods like POST for handling such information, which keeps it hidden.

POST Method

The POST method is used to send data to a server. Unlike the GET method, which only retrieves data, POST allows you to submit information that the server can use to process or store. POST is commonly used in forms, where users input data such as usernames, passwords, or contact details.

When a POST request is made, the data is sent in the body of the request rather than in the URL. This makes POST ideal for sending larger or more sensitive information, such as passwords, because the data is hidden and doesn’t appear in the browser's address bar.

For example, when you sign up for a website or submit a comment on a blog, the POST method is used to send your information to the server, which processes it and stores it in a database.

Example of a POST Request

Here’s an example of a POST request using the Fetch API to send form data to a server:

const formData = {
  username: 'john_doe',
  password: 'mypassword123'
};

fetch('https://example.com/login', {
  method: 'POST',
  headers: {
    'Content-Type': 'application/json'
  },
  body: JSON.stringify(formData)
})
.then(response => response.json())
.then(data => console.log('Success:', data))
.catch(error => console.error('Error:', error));

In this example, the POST request sends username and password as JSON data in the body of the request, making it a secure way to handle sensitive information like passwords.

Differences Between GET and POST

Although GET and POST are used to communicate with a server, they serve different purposes and handle data in different ways:

Data Transmission:

• GET: Data is included in the URL, making it visible in the address bar. This limits how much data can be sent.

• POST: Data is sent in the body of the request, which allows for sending larger amounts of information. This also keeps sensitive information hidden from the URL.

Purpose:

• GET: Used for retrieving data. It doesn’t change or modify anything on the server.

• POST: Used to send data that may change or add to the server's resources, such as adding a new user to a database or submitting a form.

Caching:

• GET: GET requests can be cached. This means that the browser may save the response, making future requests faster.

• POST: POST requests are not cached, as they often involve new or updated data that shouldn't be reused.

Idempotence:

• GET: Sending the same GET request multiple times doesn’t change the result. It will return the same data every time.

• POST: Sending the same POST request multiple times may result in different outcomes. For example, submitting a form twice could create duplicate entries.

Common Scenarios for Using POST

POST is ideal in situations where you need to send data to the server, often for processing or storage. Here are some common use cases:

1. Submitting Forms: Whenever you fill out and submit a form online, such as signing up for a newsletter or entering your details in a registration form, the POST method is used to send that information to the server. The server then processes the data, stores it, or performs another action based on it.

   • Example:

    <form action="https://example.com/register" method="POST">
      <input type="text" name="username" />
      <input type="password" name="password" />
      <button type="submit">Sign Up</button>
    </form>

2. User Authentication: When you log in to a website using a username and password, POST is often used to send your credentials securely to the server. The server checks the information and grants access to your account if the credentials match.

3. Uploading Files: POST is also used for uploading files, such as images, documents, or videos. Since the POST method allows sending large amounts of data, it’s perfect for uploading files that need to be processed or stored on the server.

   • Example using a form for file uploads:

    <form action="https://example.com/upload" method="POST" enctype="multipart/form-data">
      <input type="file" name="file" />
      <button type="submit">Upload File</button>
    </form>

4. Creating New Resources: POST is often used in APIs to create new resources. For example, when you add a new product to an online store, the POST method is used to send the product details to the server, which adds the product to the store's database.

   • Example of sending product data:

    const product = {
      name: 'New Sneakers',
      price: 59.99,
      category: 'Footwear'
    };

    fetch('https://example.com/api/products', {
      method: 'POST',
      headers: {
        'Content-Type': 'application/json'
      },
      body: JSON.stringify(product)
    })
    .then(response => response.json())
    .then(data => console.log('Product added:', data));

5. Sending Data to an API: POST is widely used in APIs when you need to send data that will be processed or stored. For example, an app that tracks your fitness progress may use POST to send your workout details to a server, where it’s stored and analyzed.

6. Making Purchases Online: When you make an online purchase, POST is used to send the payment details to the server for processing. The server processes the transaction and updates the system with your order information.

PUT Method

The PUT method is used to update or replace an existing resource on the server. It sends data to the server and tells it to create a new resource if none exists or replace the current one if it does. The key idea with PUT is that you are telling the server exactly what the resource should look like.

For example, imagine a user profile on a website. If you use PUT to update your profile, the server will replace the entire profile with the new data you provide. Every part of the profile will match exactly what you send, so if some details are missing, they will be overwritten with the new data.

Example of a PUT Request

Here’s an example of a PUT request using the Fetch API to update user data:

const updatedProfile = {
  username: 'john_doe_updated',
  email: 'john_updated@example.com',
  age: 30
};

fetch('https://example.com/users/123', {
  method: 'PUT',
  headers: {
    'Content-Type': 'application/json'
  },
  body: JSON.stringify(updatedProfile)
})
.then(response => response.json())
.then(data => console.log('Updated:', data))
.catch(error => console.error('Error:', error));

In this example, the PUT request updates the user profile with new data. The profile will be replaced with username, email, and age values. If any data is missing, such as phoneNumber, it will be removed from the profile.

When to Use PUT

PUT is mainly used when you want to update or replace a resource with specific, complete data. Here are some common situations where PUT is appropriate:

1. Updating a Resource: When you need to make changes to an existing resource, PUT is used to send a new version of the entire resource. For example, updating a blog post, product details, or user information would require sending a complete replacement of the resource using PUT.

   • Example:

    const updatedPost = {
      title: 'New Title for My Blog',
      content: 'Updated blog content here...',
      author: 'John Doe'
    };

    fetch('https://example.com/blog/45', {
      method: 'PUT',
      headers: {
        'Content-Type': 'application/json'
      },
      body: JSON.stringify(updatedPost)
    });

2. Creating a Resource if None Exists: If you send a PUT request to a specific URL that doesn't have a resource yet, the server will create one using the data you provide. This is useful when you're working with resources that need to be fully defined upfront.

   • Example of creating a product if it doesn’t exist:

    const newProduct = {
      id: 101,
      name: 'New Sneakers',
      price: 59.99,
      category: 'Footwear'
    };

    fetch('https://example.com/products/101', {
      method: 'PUT',
      headers: {
        'Content-Type': 'application/json'
      },
      body: JSON.stringify(newProduct)
    });

3. Working with APIs: When interacting with APIs, PUT is often used when you need to make updates to a resource like a user profile, product details, or any other structured data. For example, a to-do list app might allow you to use PUT to update an existing task with new information.

   • Example of updating a task:

    const updatedTask = {
      title: 'Updated Task Title',
      completed: true
    };

    fetch('https://example.com/tasks/67', {
      method: 'PUT',
      headers: {
        'Content-Type': 'application/json'
      },
      body: JSON.stringify(updatedTask)
    });

PUT vs. POST: Key Differences

Though both PUT and POST can send data to a server, they have different purposes and behaviors:

Purpose:

• PUT: Primarily used for updating or replacing an existing resource. If the resource doesn’t exist, PUT can also create it.

• POST: Mainly used to create new resources or submit data that needs to be processed. POST doesn’t replace existing resources but adds new ones.

Data Handling:

• PUT: Replaces the entire resource with the new data. If a part of the resource is missing in the request, that part gets removed or replaced.

• POST: Adds or updates resources without replacing the entire thing. For example, when submitting a form, POST adds new data to the server without deleting what’s already there.

Idempotence:

• PUT: Is idempotent, so sending the same PUT request multiple times will always result in the same outcome. No matter how many times you update a resource using PUT, the result will be the same.

• POST: Is not idempotent, so submitting the same POST request multiple times could create duplicate resources or have different results.

Use Cases:

• PUT: Best used for updates and full replacements of resources. For instance, if you’re updating product details in an online store, PUT ensures that all the details are replaced with the new ones you send.

• POST: Suited for creating new entries or sending data that requires processing. For example, submitting an online order or filling out a contact form uses POST.

PATCH Method

The PATCH method is used to make partial updates to a resource on the server. Unlike the PUT method, which replaces the entire resource, PATCH allows you to update specific parts of a resource without sending the complete data again. This makes PATCH ideal for scenarios where you only want to tweak certain details without affecting other parts of the resource.

For example, if you have a user profile and want to update only the phone number, PATCH enables you to send just the new phone number while leaving the rest of the profile unchanged. This approach is more efficient and reduces the risk of unintended data loss.

Partial Updates with PATCH

PATCH is designed for making targeted changes to a resource. Here’s how it works:

• Targeted Changes: When you use PATCH, you specify only the fields you want to update. For instance, if a user updates their email address, you send a PATCH request containing just the new email, and everything else stays the same on the server.

• Efficiency: PATCH is more efficient than PUT because it allows you to send only the data that’s being changed. This can reduce bandwidth usage, especially when updating large resources where only a small part needs modification.

• Does Not Overwrite: Unlike PUT, PATCH does not replace the entire resource. It only updates the fields that are provided in the request, ensuring that other fields remain intact.

Example of a PATCH Request

Here’s a basic example of how you might use the PATCH method to update a specific field, such as changing a user's email address:

const updatedEmail = {
  email: 'new_email@example.com'
};

fetch('https://example.com/users/123', {
  method: 'PATCH',
  headers: {
    'Content-Type': 'application/json'
  },
  body: JSON.stringify(updatedEmail)
})
.then(response => response.json())
.then(data => console.log('Email updated:', data))
.catch(error => console.error('Error:', error));

In this example, only the email field is being updated. The rest of the user profile, such as the username or address, remains unchanged.

When to Use PATCH Instead of PUT

There are specific scenarios where PATCH is more appropriate than PUT:

1. Updating Specific Fields: If you need to update only a part of a resource, like changing a user’s email, adding a tag to a blog post, or modifying a single attribute, PATCH is a better choice. It allows you to send only the fields that need updating, making the request more efficient.

   • Example: Updating a user's phone number.

    const updatedPhone = { phoneNumber: '123-456-7890' };

    fetch('https://example.com/users/123', {
      method: 'PATCH',
      headers: { 'Content-Type': 'application/json' },
      body: JSON.stringify(updatedPhone)
    });

2. Avoiding Unintended Data Loss: When using PUT, leaving out any fields could result in the server removing or overwriting those fields. PATCH avoids this risk by only updating the specific fields provided, ensuring no accidental data loss.

   • Example: If you only want to update a user’s username but don’t want to overwrite other fields like their address or preferences, PATCH ensures only the username is updated.

3. Performance Considerations: PATCH is more efficient for large resources. For instance, if you're managing a database with extensive records and need to change a small portion, PATCH reduces the data sent to the server, improving performance and speeding up the process.

   • Example: Updating the status of a large order without modifying the entire order details.

    const updatedStatus = { status: 'shipped' };

    fetch('https://example.com/orders/987', {
      method: 'PATCH',
      headers: { 'Content-Type': 'application/json' },
      body: JSON.stringify(updatedStatus)
    });

4. Frequent Updates: In applications where data changes frequently, PATCH makes it easier to update specific parts of a resource without affecting the entire structure. For instance, in an e-commerce platform, users might regularly update their shipping address or payment method, and PATCH can handle those frequent changes without requiring the entire user profile to be re-sent.

   • Example: Updating the delivery address for an order.

    const updatedAddress = {
      shippingAddress: '123 New Street, New City, Country'
    };

    fetch('https://example.com/orders/987', {
      method: 'PATCH',
      headers: { 'Content-Type': 'application/json' },
      body: JSON.stringify(updatedAddress)
    });

Key Differences Between PUT and PATCH

Here’s a quick comparison of PATCH and PUT to clarify when each method is more appropriate:

PATCH is particularly valuable when you want to make partial updates, avoid overwriting other data, and improve the efficiency of your requests.

DELETE Method

The DELETE method is used to remove a resource from the server. When a DELETE request is made, the server deletes the specified resource, meaning it’s no longer accessible or available. This method is used for tasks like deleting a user account, removing a product from an online store, or clearing old data from a database.

Unlike GET or POST, DELETE doesn’t require sending a body in the request—just the URL of the resource you want to remove is enough. For example, to delete a specific blog post, a DELETE request is sent to the URL of that post, and the server takes care of removing it.

How DELETE Works

To delete a resource, you typically only need to provide the URL of the resource you want to remove. Unlike POST or PUT requests, DELETE requests generally don’t require a body.

Example:

If you want to delete a specific blog post, you can send a DELETE request to its URL:

fetch('https://example.com/posts/123', {
  method: 'DELETE'
})
.then(response => response.json())
.then(data => console.log('Resource deleted:', data))
.catch(error => console.error('Error:', error));

This tells the server to remove the blog post with ID 123.

Safely Using DELETE

DELETE requests can have a significant impact, so it’s important to use them carefully to avoid accidentally removing valuable data. Below are some key considerations for safely handling DELETE requests:

• Permanent Action: Once a DELETE request is processed, the resource is typically gone. In some cases, systems might implement "soft delete" functionality, where the resource is hidden but not completely removed. However, most use a "hard delete," where the resource is fully erased. Soft deletes can be useful for recovery purposes, allowing data to be restored if needed.

• Authentication: DELETE requests should be restricted to authorized users. Before performing a DELETE action, the server should validate that the user has permission to delete the resource. For example, only the owner of a user account should be able to delete it, not another user.

• Confirmation: Many applications prompt users to confirm their intention before processing a DELETE action. This extra step ensures users don't accidentally delete important data, especially for irreversible actions like account deletion.

Example of a Confirmation Step:

if (confirm("Are you sure you want to delete this post?")) {
  fetch('https://example.com/posts/123', {
    method: 'DELETE'
  })
  .then(response => console.log('Post deleted'))
  .catch(error => console.error('Error:', error));
}

• Reversibility (Soft Delete): For important data, it’s often useful to implement a soft delete, which doesn’t completely remove the data but marks it as deleted in the database. This allows the data to be restored later if needed. For example, many email systems keep deleted messages in a "Trash" folder until they are permanently removed.

Best Practices for Handling DELETE Requests

1. Require Authentication: Only authenticated users should be able to perform DELETE actions. This prevents unauthorized users from deleting resources they don't own. For example, users should only be allowed to delete their own data, not that of others.

   • Example: In a content management system (CMS), ensure that only the author of a post or an admin can delete it.

2. Use Confirmation Steps: For critical actions, confirm the user’s intent before proceeding. This is especially important for actions that cannot be undone, such as deleting an account or permanently removing a file.

   • Example: Show a prompt that says, "Are you sure you want to delete your account? This action cannot be undone."

3. Log Deletions: Keep a record of DELETE requests, including who initiated the request and when it occurred. Logging is important for accountability, troubleshooting, and data recovery in case of accidental deletions.

   • Example: In an e-commerce system, log details when a product is removed from the catalog, such as the user who initiated the request and the time of deletion.

4. Soft Delete for Critical Data: Implement a soft delete mechanism for data that may need to be restored later. This is particularly useful in scenarios like user accounts, where a user might want to recover their data after deletion.

   • Example: When a user "deletes" their account, it’s marked as inactive or hidden, rather than fully erased, allowing the user to recover it later.

5. Handle Errors Gracefully: If a DELETE request fails, the server should return an appropriate error message. For example, if the resource doesn’t exist or the user isn’t authorized to delete it, the server should respond with a message like "Resource not found" or "Unauthorized action."

   • Example: A DELETE request for a non-existent user could return a 404 Not Found response.

6. Double-Check URL Targeting: Before sending a DELETE request, ensure the URL points to the correct resource. Accidentally targeting the wrong resource could result in unintended data loss.

   • Example: If you are managing a to-do list and want to delete a single task, ensure the URL points specifically to that task and not to the entire list.

7. Communicate Results to the User: After a successful DELETE request, inform the user that the resource has been deleted. This can be done through a message or notification confirming the action.

   • Example: Show a message like "Item successfully deleted" after a product or post has been removed from the system.

DELETE Response

Typically, a successful DELETE request returns one of the following status codes:

• 200 OK: Indicates that the deletion was successful and includes a response body (for example, a message confirming the deletion).

• 204 No Content: The request was successful, but no content is returned in the response body. This is common when the resource is deleted, and there’s nothing to send back.

• 404 Not Found: Indicates that the resource to be deleted does not exist.

Example of a DELETE Request Response

If the DELETE request is successful and the resource is removed, a server might respond with a 204 No Content status:

HTTP/1.1 204 No Content

This response tells the client that the resource was successfully deleted but doesn’t return any additional data.

HEAD Method

The HEAD method is similar to the GET method but with a key difference: it only retrieves the headers of a resource, not the actual content.

When you send a HEAD request, the server responds with the same headers as a GET request, but without sending the body of the resource (like text, images, or files). This makes HEAD useful for checking information about a resource, such as its size or last modified date, without downloading the entire content.

For example, if you're managing a large file and want to check its size before downloading, you can use a HEAD request to get this information from the server without actually fetching the file itself.

How HEAD Compares to GET

• Same Headers, No Content: The HEAD request provides the same headers you’d receive with a GET request, such as Content-Type, Content-Length, Last-Modified, and so on. However, the response contains no body—just the metadata.

• Faster Requests: Because no body is included, HEAD requests are faster and consume less bandwidth than GET requests. This is helpful when you're only interested in details about the resource, not the content itself.

Use Cases for HEAD

1. Checking Resource Availability: You can use a HEAD request to check whether a resource (such as a webpage or file) exists without fetching the content. For example, if a URL returns a status code like 200 OK, you know the resource is there. A 404 Not Found status code would indicate that it’s not available.

2. Testing Links: If you manage a website with numerous external links, a HEAD request can test whether those links are still valid, saving you from loading the entire page. If a HEAD request returns an error code, you know the link is broken.

3. Fetching File Metadata: If you’re dealing with large files, you might want to check their size before downloading. A HEAD request allows you to gather metadata like the file size (Content-Length) and type (Content-Type) without retrieving the entire file.

4. Optimizing Caching: Browsers and applications can use HEAD requests to check if a resource has been updated since it was cached. The server returns headers like Last-Modified or ETag, and if these values haven’t changed, the cached version can be used, saving bandwidth and time.

5. API Efficiency: HEAD requests can be useful in APIs when a client needs to verify that data exists without downloading the entire response. For example, a request could check whether a record exists in a database without fetching the full details.

6. Server Health Monitoring: HEAD requests can be used to measure server performance. By testing the speed of a response without downloading content, developers can monitor server response times, check for issues, or determine if the server is up.

Best Practices for Using HEAD

• Efficient Testing: HEAD is ideal for validating resources or testing API endpoints without downloading unnecessary data.

• Caching: HEAD requests help with cache validation, ensuring that a resource is up-to-date without consuming bandwidth.

• No Side Effects: Like GET, HEAD should be safe and idempotent, meaning it should not alter the state of the resource. It’s used purely for retrieving information.

OPTIONS Method

The OPTIONS method is used to find out what actions are allowed on a specific resource. It allows a client (like a browser or an API) to ask the server, "What operations can I perform on this resource?" In response, the server lists the HTTP methods it supports for that resource, such as GET, POST, PUT, DELETE, and so on.

OPTIONS doesn’t perform any operation on the resource itself. Instead, it provides information about what the client can do. This makes it useful when you want to check what actions are allowed before actually making a request that changes or retrieves data.

For example, if you’re working with an API and want to see if it supports a DELETE method on a particular endpoint, you can send an OPTIONS request to get that information without affecting the resource.

Retrieving Supported Methods

1. Sending an OPTIONS Request: The client sends an OPTIONS request to a server, typically targeting a specific URL. This request serves as an inquiry about what actions are permitted on the resource at that endpoint.

2. Server’s Response: The server responds with an Allow header that lists the available HTTP methods for the resource. For example, it might return Allow: GET, POST, DELETE, meaning those methods can be used.

3. Testing for Methods: If you're unsure whether a particular method (like PATCH or DELETE) is supported by a server, you can send an OPTIONS request first to check. This avoids attempting methods that the server doesn’t support, which could result in errors.

Example:

OPTIONS /api/resource HTTP/1.1
Host: example.com

Server Response:

HTTP/1.1 200 OK
Allow: GET, POST, DELETE

How OPTIONS is Used in Cross-Origin Resource Sharing (CORS)

One of the most common uses of the OPTIONS method is in handling Cross-Origin Resource Sharing (CORS). CORS is a security feature that ensures resources on one domain aren’t accessed improperly by web pages from another domain.

CORS and Preflight Requests

When a browser needs to make a cross-origin request (for example, a request from domainA.com to api.domainB.com), the browser first sends an OPTIONS request, known as a preflight request, to the target server. The preflight request checks whether the actual request is allowed under the server’s CORS policy.

1. Preflight Request: The browser sends an OPTIONS request before the actual request (such as a POST or PUT). This request asks the server which methods are allowed, which domains can access the resource, and whether specific headers or credentials are permitted.

2. Server’s Response: The server responds with CORS headers, such as Access-Control-Allow-Methods, Access-Control-Allow-Origin, and Access-Control-Allow-Headers. This tells the browser whether the request can proceed and what methods or domains are allowed.

   Example Response:

    HTTP/1.1 204 No Content
    Access-Control-Allow-Origin: https://domainA.com
    Access-Control-Allow-Methods: GET, POST
    Access-Control-Allow-Headers: Content-Type
   

3. Ensuring Security: CORS and the preflight OPTIONS request ensure that cross-origin requests are only allowed when the server permits it. Without this security step, websites could make unauthorized requests to other domains.

4. Handling Complex Requests: If a request includes custom headers, uses HTTP methods other than simple ones like GET or POST, or sends credentials like cookies, the browser automatically sends an OPTIONS preflight request. If the server denies the request (that is, returns headers disallowing the action), the browser blocks the request.

Simplified Workflow:

• Browser: "Can I make this request to api.domainB.com?"

• Server: "Yes, you can use GET and POST, but only from domainA.com and with these headers."

• Browser: Proceeds with the actual request if the response permits.

Use Cases for the OPTIONS Method

• Discovering Available Methods: Useful for developers to check which HTTP methods a resource supports before performing an operation.

• CORS Preflight: Critical in web security to ensure that cross-origin requests are properly authorized.

• Improving API Efficiency: APIs can expose the supported methods for a resource via OPTIONS, making it easier for clients to understand what operations can be performed.

The OPTIONS method is thus essential in web applications for managing request permissions and improving security, particularly in cross-domain scenarios.

TRACE Method

The TRACE method is used to debug web applications and test how requests pass through networks. When you send a TRACE request, it triggers a loopback, where the server sends back the exact request it received, without any changes. This helps developers see if anything is modified as the request travels through different systems, like firewalls or proxies, before reaching the server.

In simple terms, TRACE allows you to trace the path your request takes from your client (like a browser or API tool) to the server and back. This method can be useful for identifying issues during the transmission of a request.

Understanding Loopback Diagnostics

Loopback diagnostics refers to the process of seeing how data is handled as it moves across networks, using TRACE to check if the original request remains intact. Here’s how it works:

1. Sending a TRACE Request: You send a TRACE request to a server. This request is usually small, containing basic information like the method, URL, and headers. It doesn't carry any extra data or payload like POST or PUT methods.

2. Server’s Response: Instead of responding with a resource, the server sends back the exact request it received. This includes the HTTP method, the URL, headers, and anything else in the original request. The server doesn’t modify or process the request—it just returns it exactly as it was received.

3. Tracing the Path: When the TRACE response comes back, it allows you to see the entire path the request took, including any changes made to the request headers or content. This is useful for diagnosing issues such as:

   • Proxy Servers: If your request passes through one or more proxy servers before reaching the destination, TRACE can show if those proxies have altered the request headers or content.

   • Network Firewalls: Some network firewalls might add or modify headers as your request passes through them. TRACE helps reveal these modifications.

   • Error Tracking: If a request fails to behave as expected, TRACE can help track where something went wrong in the transmission.

4. Effective Debugging: TRACE is especially helpful when debugging web applications or APIs. If your application is experiencing errors due to routing, proxies, or server configurations, TRACE lets you see the unaltered request, making it easier to pinpoint the issue.

Security Concerns with TRACE

Although TRACE can be useful for debugging, it is generally considered a security risk and is often disabled on most servers for several reasons:

1. XSS Attacks (Cross-Site Scripting): TRACE can expose sensitive information such as cookies or authentication tokens in the headers. Malicious actors could exploit TRACE to capture these details, leading to security breaches, especially if a vulnerability like cross-site scripting (XSS) is present. This makes TRACE a potential target for attackers trying to steal user data.

2. Request Modification Exposure: Since TRACE shows all modifications made to a request, it can also reveal how internal proxies and firewalls handle requests. This could give attackers insight into the internal workings of a network, making it easier for them to plan further attacks.

3. Disabling TRACE for Safety: For these reasons, TRACE is often disabled on most web servers to prevent abuse. In many modern web applications, more secure methods exist for debugging requests and tracing network paths, so TRACE is rarely necessary in everyday use.

4. Safer Alternatives: Developers can use safer diagnostic tools and logging features built into modern web frameworks and APIs. These alternatives provide similar insights without exposing security risks associated with TRACE.

CONNECT Method

The CONNECT method is mainly used to establish a tunnel between a client and a server through an intermediary, usually a proxy server. When the client sends a CONNECT request, the server creates a tunnel that allows encrypted data to flow between the client and the destination server. This method is crucial for securing connections, especially when dealing with HTTPS.

CONNECT does not handle any actual data on its own. Instead, it sets up a path for secure communication, allowing encrypted information to pass through proxies without being modified or inspected.

How CONNECT Works

1. Sending a CONNECT Request: A client, such as a web browser, sends a CONNECT request to the proxy server. This request includes the target server's hostname and port, typically the standard HTTPS port (443). For example, when accessing https://example.com, the browser sends a CONNECT request to the proxy server asking it to connect to that domain on port 443.

2. Establishing the Tunnel: The proxy server, upon receiving the CONNECT request, establishes a tunnel to the destination server. This tunnel allows encrypted communication to pass through without interference. The proxy simply forwards traffic between the client and the destination, acting as a relay.

3. Encrypted Communication: Once the tunnel is set up, the client and the destination server can communicate directly using a secure encryption protocol, such as TLS (used by HTTPS). The proxy cannot decrypt or modify the data passing through because it’s encrypted between the client and the server.

4. Secure Data Transfer: With the CONNECT method, sensitive data—such as login credentials, personal information, or financial transactions—can be transmitted securely between the client and the server, even when passing through proxies. The encrypted tunnel ensures that the data remains confidential and intact.

Example of a CONNECT Request and Response

• CONNECT Request:

    CONNECT example.com:443 HTTP/1.1
    Host: example.com
  

• Proxy Response (if the tunnel is successfully established):

    HTTP/1.1 200 Connection Established
  

Tunneling with CONNECT

The term tunneling in this context refers to creating a direct, secure link between the client and the destination server via a proxy. The proxy acts as a middleman but does not interfere with or access the encrypted data being transmitted through the tunnel.

Steps of the Tunneling Process:

• Sending the CONNECT Request: The client sends a CONNECT request to the proxy, specifying the destination server and port (for example, port 443 for HTTPS).

• Proxy Sets Up the Tunnel: The proxy server establishes a secure tunnel between the client and the destination server, forwarding traffic between the two endpoints.

• Encrypted Communication Begins: The client and the destination server communicate directly through the encrypted tunnel using HTTPS or another encryption protocol. The proxy forwards the encrypted traffic but cannot access or modify it.

Typical Use Cases of the CONNECT Method

1. HTTPS Through Proxies: One of the most common uses of the CONNECT method is enabling HTTPS traffic through proxies. In many corporate or network environments, internet traffic must pass through a proxy server. For secure websites using HTTPS, the CONNECT method allows the proxy server to establish a tunnel, forwarding encrypted traffic between the client and the destination server without inspecting the data.

   • Example: When you visit a secure banking website from a corporate network, your browser may need to pass through a corporate proxy. The CONNECT method is used to establish an encrypted tunnel between your browser and the bank's website, allowing sensitive data (such as login credentials) to pass through the proxy securely.

2. VPNs and Secure Channels: VPN (Virtual Private Network) services also rely on similar tunneling techniques to encrypt and route internet traffic securely. Some VPN services use CONNECT to create secure tunnels, ensuring that all data transmitted between the user and the internet is encrypted and safe from eavesdropping.

3. Accessing Blocked Content: In environments where certain websites are blocked (for example, schools or offices), CONNECT can sometimes be used to bypass restrictions by establishing a tunnel through a proxy. Although this practice may violate network policies, it illustrates how CONNECT can be used to establish secure, unmonitored access to otherwise blocked resources.

4. Custom Proxies: Developers may set up custom proxies to route application traffic for performance or security reasons. In these cases, CONNECT allows HTTPS or other secure traffic to pass through the proxy while maintaining privacy and security, as the proxy server cannot access the encrypted data inside the tunnel.

Security Considerations

While CONNECT is essential for secure communications, it also presents some security challenges:

• Bypassing Content Filters: Since CONNECT creates an encrypted tunnel that proxies cannot inspect, it can be used to bypass content filtering systems. This allows users to access restricted websites or services, which may violate organizational policies.

• Tunneling Malicious Traffic: CONNECT can be exploited by malicious actors to tunnel harmful or unauthorized traffic through a proxy. Because the traffic is encrypted, firewalls and security systems may not detect malicious activity.

• Mitigation: Many organizations address these risks by closely monitoring and restricting the use of the CONNECT method. Some proxies perform SSL interception to decrypt and inspect HTTPS traffic, though this introduces privacy concerns and may compromise user security.

Conclusion

HTTP methods are essential in enabling communication between web applications and servers. Each method, from GET to CONNECT, is designed for a specific task, such as sending data, retrieving information, updating resources, or setting up secure connections. Choosing the correct method for the job improves the efficiency and security of your application.

GET is ideal for retrieving data, POST and PUT help with creating and updating, PATCH handles partial updates, and DELETE removes resources. HEAD checks response headers without retrieving content, OPTIONS shows supported methods, and TRACE and CONNECT assist with debugging and secure communication.

Using the appropriate HTTP methods ensures your application runs efficiently and securely, offering a smooth experience for users.

If you have any questions or suggestions, feel free to reach out on LinkedIn. If you enjoyed this content, consider buying me a coffee to support the creation of more developer-friendly contents.

This action will send an HTTP request to the backend, along with all the necessary data, and the backend application will use that data to make changes to the database. After the action is complete, whether successful or not, an HTTP response will be sent back to the frontend, which will act accordingly based on the status of that response.

When these requests and responses are transferred back and forth, they need to follow a certain format so that both ends can understand each other. HTTP was created for this purpose. It is a standard network protocol that enables web applications to understand and communicate with each other.

What Are the HTTP Request Methods?

There are several methods you can use to send an HTTP request, and each of them serves a different purpose, as shown below:

The GET Method

The GET method is used to request data and resources from the server. When you send a GET request, the query parameters are embedded in the URL in name/value pairs like this:

http://example.com/index.html?name1=value1&name2=value2

Note that the question mark (?) denotes the beginning of a list of parameters. Each parameter forms a key/value pair (name=value), and the ampersand (&) is used to divide two different parameters.

The POST Method

The POST method is used to send data to the server, either adding a new resource or updating an existing resource. The parameters are stored in the body of the HTTP request.

POST /index.html HTTP/1.1
Host: example.com
name1=value1&name2=value2

The DELETE Method

This method removes a resource from the server.

The HEAD Method

The HEAD method works just like GET except that the HTTP response sent from the server will only contain the head but not the body. This means that if the server is "OK" with the request, it will give you a 200 OK response but not the resource you requested. You can only retrieve the resource with the GET method.

This is very useful when you are testing whether the server works. Sometimes, the resource may take a long time to be transmitted, and for testing purposes, you only need a 200 OK response to know that everything works properly.

The PUT Method

The PUT method is used to update existing resources, and it is similar to the POST method with one small difference.

When you PUT a resource that already exists, the old resource will be overwritten. And making multiple identical PUT requests will have the same effect as making it once.

When you POST identical resources, that resource will be duplicated every time the request is made.

What is the Fetch API?

For a long time, the JavaScript community lacked a standard way to send HTTP requests. Some people used XMLHttpRequest, aka AJAX, while others prefered external libraries such as Axios or jQuery.

The fetch API was introduced in 2015 as the modern, simplified, and standard way of making HTTP requests using JavaScript. It is natively supported, so there is no need to install any third-party libraries.

How to Send a GET Request Using JavaScript

The fetch API is promise-based, which means that it offers a clean and concise syntax for writing asynchronous operations. For example, this is how you can send a GET request using the fetch API.

fetch("https://jsonplaceholder.typicode.com/users")
  .then((response) => {
    // If the response is not 2xx, throw an error
    if (!response.ok) {
      throw new Error("Network response was not ok");
    }

    // If the response is 200 OK, return the response in JSON format.
    return response.json();
  })
  .then((data) => console.log(data)) // You can continue to do something to the response.
  .catch((error) => console.error("Fetch error:", error)); // In case of an error, it will be captured and logged.

You can also include custom options with the request, such as custom headers, authorization tokens, and so on.

fetch("https://jsonplaceholder.typicode.com/users", {
  headers: {
    "Content-Type": "application/json",
    "Authorization": "your-token-here",
  },
  credentials: "same-origin",
})
  .then(. . .);

How to Send a POST Request Using JavaScript

When sending a POST request, things get a bit more complex because you need to send data to the server with the request body. This could get complicated depending on the kind of data you're sending and your specific use case.

For example, the following code sends JSON data to the backend:

fetch("https://jsonplaceholder.typicode.com/users", {
  method: "POST",
  headers: {
    "Content-Type": "application/json",
  },
  body: JSON.stringify({
    name: "John Doe",
    email: "johndoe@example.com",
  }),
});

There are a few things you must pay attention here. First of all, you must explicitly specify the request method. If you leave this out, the default GET method will be used.

Also, the request body only accepts string data, so you must use the stringify() method to convert JSON into a string before assigning it to the request body.

This is also why it is important to include the Content-Type header, which lets whoever is on the receiving end know how to parse the request body.

However, things are usually more complex in practice. For example, when working with web forms, instead of JSON, you are likely using the x-www-form-urlencoded form encoding, in which case the request can be sent like this.

The following example assumes you understand what event handlers are.

document.addEventListener("DOMContentLoaded", function () {
  const form = document.querySelector("form");
  const usernameInput = document.getElementById("username");
  const emailInput = document.getElementById("email");

  const formData = new URLSearchParams();

  usernameInput.addEventListener("input", function () {
    formData.set("username", usernameInput.value);
  });

  emailInput.addEventListener("input", function () {
    formData.set("email", emailInput.value);
  });

  form.addEventListener("submit", async function (event) {
    event.preventDefault(); // Prevent the default form submission action

    await fetch("https://jsonplaceholder.typicode.com/users", {
      method: "POST",
      body: formData.toString(),
      headers: {
        "Content-Type": "application/x-www-form-urlencoded",
      },
    });
  });
});

If you need to upload files to the backend, you'll need the multipart/form-data form encoding instead.

document.addEventListener("DOMContentLoaded", function () {
  const form = document.getElementById("myForm");
  const usernameInput = document.getElementById("username");
  const emailInput = document.getElementById("email");
  const pictureInput = document.getElementById("picture");

  const formData = new FormData();

  usernameInput.addEventListener("input", function () {
    formData.set("username", usernameInput.value);
  });

  emailInput.addEventListener("input", function () {
    formData.set("email", emailInput.value);
  });

  pictureInput.addEventListener("change", function () {
    formData.set("picture", pictureInput.files[0]);
  });

  form.addEventListener("submit", async function (event) {
    event.preventDefault(); // Prevent the default form submission

    await fetch("https://jsonplaceholder.typicode.com/users", {
      method: "POST",
      body: formData,
    });
  });
});

Note that when using the FormData() to construct the request body, the Content-Type will be locked into multipart/form-data. In this case, it is not necessary to set a custom Content-Type header.

How to Send a PUT Request Using JavaScript

The PUT request works similarly to POST, but you must remember to set method to PUT.

fetch("https://jsonplaceholder.typicode.com/users", {
  method: "PUT",
  headers: {
    "Content-Type": "application/json",
  },
  body: JSON.stringify({
    id: "123"
    name: "John Doe",
    email: "johndoe@example.com",
  }),
});

Realistically, you'll have to provide an id, or any other key that enables you to locate the record to be updated in the backend.

How to Send a DELETE Request Using JavaScript

The DELETE request works similarly to PUT, but remember to set method to DELETE.

fetch("https://jsonplaceholder.typicode.com/users/123", {
  method: "DELETE",
});

And similarly, remember to provide an id so that the backend application knows which record to delete.

How to Send a Request Using XMLHttpRequest (AJAX)

Besides fetch(), it is also possible to make an HTTP request using XMLHttpRequest. The following example demonstrates how to make a GET request to the endpoint https://jsonplaceholder.typicode.com

var xhr = new XMLHttpRequest();
xhr.open("GET", "https://jsonplaceholder.typicode.com/users", true);
xhr.onload = function () {
  if (xhr.status >= 200 && xhr.status < 300) {
    console.log(JSON.parse(xhr.responseText));
  } else {
    console.error("Error:", xhr.statusText);
  }
};
xhr.onerror = function () {
  console.error("Request failed");
};
xhr.send();

The syntax is a bit more complex, as XMLHttpRequest relies on callback functions to work with asynchronous operations, which means it is easy to lead to what is known as the callback hell, where you have layers upon layers of callback functions, making your code base difficult to read and maintain.

However, XMLHttpRequest does have some advantages. Due to the fact that XMLHttpRequest is much older compared to fetch(), it is more widely supported. You should consider using XMLHttpRequest when your web app needs to be compatible with older browsers.

How to Send a Request Using External Libraries

Aside from the built-in methods, you can also send HTTP requests using third-party libraries. For instance, this is how you can send a GET request using jQuery:

$.get("https://api.example.com/data", function (data) {
  console.log(data);
}).fail(function (error) {
  console.error("Error:", error);
});

jQuery is one of the most popular JavaScript libraries. It aims to fix the part of JavaScript that is difficult to use, and it has been pretty successful at that.

In recent years, jQuery has lost some popularity as vanilla JavaScript has improved over the years and the problems that used to bother people have been fixed. It is no longer the go-to choice for creating JavaScript applications, especially for newer developers.

Alternatively, you could go with Axios, which is a promise-based HTTP client just like fetch(), and it has been people's favorite for a very long time before fetch() came.

axios
  .get("https://api.example.com/data")
  .then((response) => console.log(response.data))
  .catch((error) => console.error("Axios error:", error));

Axios and fetch() have very similar syntax as they are both promise-based. The main difference between them is that fetch() is built-in, while Axios requires you to install an external library. However, Axios is much more feature-rich, as it comes with request/response interceptors, automatic JSON handling, and built-in timeouts.

Conclusion

We introduced four different ways you could send HTTP requests using JavaScript in this tutorial. It is up to you to decide which is best for your project.

The fetch API is the modern and standard way of making HTTP requests using JavaScript. It has a relatively simple syntax, which makes your project easier to maintain.

XMLHttpRequest is the legacy method of sending HTTP requests. It is generally not recommended for use in new projects, but if your project needs to be compatible with legacy browsers, XMLHttpRequest might still come in handy.

jQuery is an external package that can do a lot of things, including sending HTTP requests. Although the significance of jQuery has been fading in recent years, it is still used in many older projects, and you might encounter it in your work as a JavaScript developer.

Axios is a third-party library used to send HTTP requests. It has a very similar syntax to the fetch API but comes with a lot more advanced features. It is up to you to decide if you need these features. If not, it is generally recommended to use fetch() instead.

To learn more about JavaScript and web development, visit thedevspace.io

For example, let's say you have a button that only opens a door when pressed. This button does not have the ability to close the door, so it stays open even when it's pressed repeatedly. It simply remains in the state it was changed to by the first press.

This same logic applies to HTTP methods that are idempotent. Operating on idempotent HTTP methods repeatedly won't have any additional effect beyond the initial execution.

Understanding idempotence is important for maintaining the consistency of HTTP methods and API design. Idempotence has a significant impact on API design, as it influences how API endpoints should behave when processing requests from clients.

In this tutorial, I'll explain the concept of idempotence and the role it plays in building robust and functional APIs. You'll also learn about what safe methods are, how they relate to idempotence, and how to implement idempotency in non-idempotent methods.

Prerequisites

Before understanding and implementing idempotence in API design, it's essential to have a solid foundation in the following areas:

• RESTful Principles
• Fundamentals of HTTP methods
• API Development
• HTTP Status codes
• Basics of Web development.

Idempotence Example

Let's start off with an example of idempotence in action. We'll create a function that uses the DELETE method to delete data from a web page:

from flask import Flask, jsonify, abort

app = Flask(__name__)

web_page_data = [
   {"id": 1, "content": "Row 1 data"},
   {"id": 2, "content": "Row 2 data"},
   # Add more rows as needed
]

@app.route('/delete_row/<int:row_id>', methods=['DELETE'])
def delete_row(row_id):
   # Find the row to delete
   row_to_delete = next((row for row in web_page_data if row["id"] == row_id), None)

   if row_to_delete:
       # Simulate deletion
       web_page_data.remove(row_to_delete)
       return jsonify({"message": f"Row {row_id} deleted successfully."}), 200
   else:
       abort(404, description=f"Row {row_id} not found.")

if __name__ == '__main__':
   app.run(debug=True)

This function is expected to delete the rows chosen by the user. Now because of the idempotent nature of the DELETE method, the data will be deleted once, even when called repeatedly. But subsequent calls will return a 404 error since the data has already been deleted by the first call.

Let’s look at another example with the GET method. The GET method is used to retrieve data from a resource. Let’s create a function that uses the GET method to retrieve a username:

import requests

def get_username():
    url = 'https://api.example.com/get_username'
    try:
        response = requests.get(url)
        if response.status_code == 200:
            return response.json()['username']
        else:
            return None
    except requests.RequestException as e:
        print(f"Error occurred: {e}")
        return None

# Usage
username = get_username()
if username:
    print(f"The username is: {username}")
else:
    print("Failed to retrieve the username.")

In this example, we define the get_username() function, which sends a GET request to the API endpoint to retrieve the username. If the request is successful, we extract the username from the JSON response and return it. But if any error occurs during the request, we handle it and return None.

Now the idempotent nature of the GET method ensures that even if you call get_username() multiple times, the same username will be fetched from the API each time. The result will always be the same which is to fetch the username from the resource.

Idempotent vs. Non-Idempotent HTTP Methods:

HTTP methods play crucial roles in determining how data is fetched, modified, or created when interacting with APIs. And Idempotency is one of the important concepts that influences data consistency and reliability in the methods used .

Here's a breakdown of the different methods based on their idempotency.

Idempotent methods:

• GET
• HEAD
• PUT
• DELETE
• OPTIONS
• TRACE

Non-idempotent methods:

• POST
• PATCH
• CONNECT

Safe Methods

In our previous example, we used the GET method to retrieve a username and this had no side effect on the server. This is because it is a safe method.

A safe method is a type of method that doesn’t modify the server’s state or the resource being accessed. In other words, they perform read-only operations used to retrieve data or for resource representation.

When you make a request using a safe method, the server does not perform any operations that modify the resource's state. Like in our previous example, we retrieved the username from the webpage which is the resource without changing anything in the server.

All safe methods are automatically idempotent, but not all idempotent methods are safe. This is because while idempotent methods produce consistent results when called repeatedly, some of them may still modify the server's state or the resource being accessed.

Like in our first example, the DELETE method is idempotent, because deleting a resource multiple times will have the same effect. But it's not safe, as it changes the server's state by removing the resource.

Here’s a classification of HTTP methods based on their safe status:

Safe methods:

• GET
• OPTIONS
• HEAD

Unsafe methods:

• DELETE
• POST
• PUT
• PATCH

Why is POST not idempotent?

POST is an HTTP method that sends information to a server. When you make a POST request, you typically submit data to create a new resource or trigger a server-side action. Therefore, making the same request multiple times can result in different outcomes and side effects on the server. This can lead to duplicated data, starting server resources, and reducing performance because of the repeated action.

Unlike idempotent methods like GET, PUT, and DELETE, which have consistent results regardless of repetition, POST requests can cause changes to the server's state with each invocation.

POST requests often create new resources on the server. Repeating the same POST request will generate multiple identical resources, potentially leading to duplication.

This is similar to DELETE which is an idempotent method but not a safe method. Deleting the last entry in a collection using a single DELETE request would be considered idempotent. But if a developer creates a function that deletes the last entry, that would trigger DELETE multiple times. Subsequent DELETE calls would have different effects, as each one removes a unique entry. This would be considered non-idempotent.

How to Achieve Idempotency with Non-Idempotent Methods

Idempotency isn't only a property inherent to certain methods – it can also be implemented as a feature of a non-idempotent method.

Here are some techniques to achieve idempotency even with non-idempotent methods.

Unique Identifiers

Adding unique identifiers to every request is one of the most common techniques used to implement idempotency. It works by tracking whether the operation has already been performed or not. If it's a duplicate (a repeat request), the server knows it's already dealt with that request and simply ignores it, ensuring that no side effects occur.

Here's an example of how it works:

from uuid import uuid4

def process_order(unique_id, order_data):
    if Order.objects.filter(unique_id=unique_id).exists():
        return HttpResponse(status=409)  # Conflict
    order = Order.objects.create(unique_id=unique_id, **order_data)
    return HttpResponse(status=201, content_type="application/json")

# Example usage
post_data = {"products": [...]}
headers = {"X-Unique-ID": str(uuid4())}
requests.post("https://api.example.com/orders", data=post_data, headers=headers)

In this code snippet, we define a function called process_order that creates orders in an API, using unique identifiers to implement idempotency.

Here's a breakdown of the code:

Importing the Unique Identifier Generator:

from uuid import uuid4: The code snippet starts by importing the uuid4 function from the uuid module. This function generates unique identifiers, which are used to achieve idempotency in this code.

Defining the process_order Function:

def process_order(unique_id, order_data): This line defines a function named process_order that takes two arguments:

• unique_id: This is a string representing a unique identifier for the request. This ensures no duplicate orders are created with the same identifier.
• order_data: This is a dictionary containing the actual order data, like product information and customer details.

Checking for Existing Orders:

if Order.objects.filter(unique_id=unique_id).exists(): This line checks if an order with the same unique_id already exists in the database.

Order.objects.filter(unique_id=unique_id).exists() queries the Order model for orders with the matching unique_id and checks if any orders were found in the query result. If an order is found, it means the same request was already processed.

Handling existing orders:

return HttpResponse(status=409): If an order with the same unique_id already exists, the function immediately returns an HTTP response with status code 409 indicating a conflict. This prevents duplicate orders from being created.

Creating a new order (if unique):

order = Order.objects.create(unique_id=unique_id, **order_data ): This line only runs if no existing order is found.

Order.objects.create: creates a new object in the Order model.

unique_id=unique_id sets the unique_id attribute of the new order to the provided unique_id.

order_data: spreads the dictionary order_data as keyword arguments to the order model's constructor, setting other relevant attributes like products and customer information.

Sending a success response:

return HttpResponse(status=201, content_type="application/json"): If the order creation is successful, the function will return an HTTP response with status code 201 which shows a successful creation. It also specifies the response content type as JSON, assuming the order data might be returned in JSON format.

post_data = {"products": [...]}: an example request, defines a dictionary containing the actual order data, like a list of products.

headers = {"X-Unique-ID": str(uuid4())}: This line creates a dictionary containing a custom header named X-Unique-ID. It generates a unique identifier string using uuid4() and adds it to the header.

requests.post("https://api.example.com/orders", data=post_data, headers=headers): This line sends a POST request to the API endpoint https://api.example.com/orders with the provided post_data and headers.

How does this implement idempotence?

It does so by using a unique identifier (unique_id) for each order.

It checks if an order with the same identifier already exists in the database. If it returns true, it returns a 409 Conflict status. Otherwise, it creates a new order and responds with a 201 Created status. The unique identifier prevents duplicate orders, making the system idempotent.

Token-based Authorization

Token-based authorization is a form of authorization that assigns temporary tokens for each non-idempotent action. Once the action is completed, the token is invalidated. If the same request comes again with the same token, the server recognizes it as invalid and refuses the request, thereby preventing duplicate actions.

// Generate a unique token for this action
const token = generateToken();

fetch("https://api.example.com/create-user", {
    method: "POST",
    body: JSON.stringify({ username, password }),
    headers: {
        Authorization: `Bearer ${token}`,
        "Content-Type": "application/json",
    },
})
    .then(response => {
        // Handle successful response
        if (response.ok) {
            // Do something with the successful response
        } else {
            // Handle non-successful response
        }
    })
    .catch(error => {
        // Handle error
        console.error("Error occurred:", error);
    })
    .finally(() => {
        // Invalidate token after successful action or in case of an error
        invalidateToken(token);
    });

// Simple implementation for generating a token
function generateToken() {
    return Math.random().toString(36).substr(2);
}

// Simple implementation for invalidating a token
function invalidateToken(token) {
    // Add your logic to invalidate the token, e.g., remove it from storage
}

Here's a breakdown of the code:

Generating a unique token:

const token = generateToken(): This line calls a function named generateToken() (which is assumed to be defined elsewhere) that generates a unique token string. This token will be used for authorization and idempotency.

Sending the POST request:

fetch("https://api.example.com/create-user", { ... }): This line uses the fetch API to send a POST request to the API endpoint https://api.example.com/create-user.

method: "POST": This specifies the HTTP method as POST, indicating the intention to create a new user.

body: JSON.stringify({ username, password }): This defines the request body with user details like username and password. The data is converted to JSON format before sending.

headers: { Authorization:Bearer ${token}}: This sets the Authorization header in the request. The header value includes the generated token prefixed with "Bearer ".

Handling the Response:

.then(response => { ... }): This block defines the code to execute if the request is successful. You would handle things like storing user information or redirecting the user upon successful user creation.

.catch(error => { ... }): This block defines the code to execute if the request encounters an error. You would handle any error messages or handle specific error scenarios here.

Invalidating the Token:

invalidateToken(token): This line calls a function named invalidateToken(token) ( which is assumed to be defined elsewhere) which would likely mark the used token as invalid. This ensures the same token cannot be used for subsequent requests, adding to the idempotency guarantee.

How does this implement Idempotence?

This code snippet uses token-based authorization to implement idempotency in a POST request to create a user on an API. If a user creation request is accidentally sent multiple times, a new unique token is generated each time and used in the Authorization header.

The API server can recognize and verify the unique token, and since the user creation action has already been performed (assuming it's successful the first time), it won't create duplicate users due to subsequent identical requests.

ETag Header:

An ETag header (Entity Tag) is an HTTP header used for web cache validation and conditional requests. It is mainly used for PUT requests, that only update resources if they haven't changed since the last check.

When you want to update a resource, the server sends you its ETag which is then included in your PUT request along with the updated data. If the ETag hasn't changed (meaning the resource remains the same), the server accepts the update. But if the ETag has changed, the server rejects the update, preventing it from overwriting someone else's changes.

def update_article(article_id, content):
    # Get existing article and its ETag
    article = Article.objects.get(pk=article_id)
    etag = article.etag

    # Check if ETag matches with request header
    if request.headers.get("If-Match") != etag:
        return HttpResponse(status=409)  # Conflict

    # Update article content and generate new ETag
    article.content = content
    article.save()
    new_etag = article.etag

    # Return success response with updated ETag
    return HttpResponse(status=200, content_type="text/plain", content=new_etag)

In this code snippet, we define a function called update_article that allows you to update the content of an existing article based on its ID and new content. It implements idempotency using the ETag header technique.

Here's a step-by-step explanation of how it works;

Getting the Existing Article and its ETag:

article = Article.objects.get(pk=article_id): This line fetches the article with the provided article_id from the database using the Article model.

etag = article.etag: This line extracts the ETag value from the retrieved article object. The ETag serves as a unique identifier for the article's current state.

Checking for a Match:

if request.headers.get("If-Match") != etag: This line checks if the ETag header provided in the request matches the ETag of the retrieved article.

return HttpResponse(status=409): If the ETag doesn't match, it indicates that the article might have been updated by another request since the client retrieved its information. The function returns a 409 Conflict response, which prevents accidental data corruption.

Updating the Article Content and generating a new ETag:

article.content = content: This line updates the article's content with the new content received in the request.

article.save(): This line saves the updated article back to the database.

new_etag = article.etag: This line retrieves the new ETag generated for the updated article after saving it.

Returning the Success Response with the new ETag:

return HttpResponse(status=200, content_type="text/plain", content=new_etag): returns a successful 200 OK response, including the content type ("text/plain") and the updated ETag of the article in the response body.

How does this implement idempotence?

This code ensures that if the same update request is sent multiple times with the same ETag, the update will only be performed once, preventing duplicate updates and maintaining data consistency. The new ETag is then provided in the response to help the client keep track of the article's state for future interactions.

Conclusion

In this tutorial, we highlighted the difference between safe methods like GET, which retrieves data without side effects, and non-idempotent methods like POST, which can have different outcomes with each repetition.

We also explored techniques you can apply to achieve idempotence in non-idempotent methods, emphasizing the importance of designing APIs that prioritize consistency and reliability.

One crucial aspect of HTTP is the request method, which indicates the type of operation the client wants to perform on a resource.

This article will explore three common HTTP request methods — Call, Put, and Post — and their applications in JavaScript web development.

How HTTP Works

HTTP (Hypertext Transfer Protocol) is the foundation of communication on the World Wide Web. It is a protocol that governs how data is transmitted and received between clients (web browsers) and servers (web servers) over the internet.

When you enter a URL (Uniform Resource Locator) in your web browser and hit enter, your browser sends an HTTP request to the server hosting the website associated with that URL. The server then processes the request and sends back an HTTP response containing the requested data, such as a webpage, an image, or other resources.

HTTP uses a client-server model, where the client (typically a web browser) sends requests to the server, and the server responds with the requested data. One important aspect of HTTP is the concept of request methods, also known as HTTP verbs or methods.

Request methods are used to indicate the type of operation the client wants to perform on a resource on the server. HTTP defines several request methods, including Call, Put, Post, Delete, and more, each with its specific purpose and behavior.

These request methods are used to communicate the client's intention to the server and determine how the server should handle the request. Let's focus on three common request methods: Call, Put, and Post.

How to Use the Call Method

In the context of an HTTP Request, the call method is called the GET method. It is used to retrieve data from a resource on the server. When you make a Call request, you ask the server to provide you with the data of a particular resource.

The Call method is considered "safe" and "idempotent." This means it should not have any side effects on the server and can be repeated multiple times without changing the outcome. In other words, making the same Call request multiple times should not result in any changes on the server.

In JavaScript web development, you often use the Call method to fetch data from APIs or retrieve resources from the server.

For example, you may use the Fetch API in JavaScript to request a Call to an API and retrieve data in JSON format:

fetch("https://jsonplaceholder.typicode.com/posts?_limit=5")
  .then((response) => response.json())
  .then((data) => console.log(data))
  .catch((error) => console.error(error));

In this example, the Call request is made to the URL ‘https://jsonplaceholder.typicode.com/posts’ to fetch data from the server (?_limit=5 is added to reduce the data fetched from 100 to 5). The response from the server is then parsed as JSON, and the retrieved data is logged to the console. You can now make use of the data within your application.

How to Use the Put Method

The Put method is used to update data on the server or create a new resource if it does not already exist.

When you make a Put request, you ask the server to update the data of a particular resource or create a new resource with the provided data.

The Put method is considered "idempotent" but not "safe." This means that making the same Put request multiple times will not result in different outcomes but may have side effects on the server.

In JavaScript, you can use the Put method to send data to the server to update resources. For example, you may use the Fetch API to make a Put request with updated data to update a user's profile information on the server:

const dataToUpdate = {
  id: 1,
  title: "Hello freeCodeCamp",
  body: "Welcome to freeCodeCamp",
  userId: 1
};

fetch("https://jsonplaceholder.typicode.com/posts/1", {
  method: "PUT",
  headers: {
    "Content-type": "application/json; charset=UTF-8"
  },
  body: JSON.stringify(dataToUpdate)
})
  .then((response) => response.json())
  .then((data) => console.log(data))
  .catch((error) => console.error(error));

In this example, the Put request is made to the URL ‘https://jsonplaceholder.typicode.com/posts/1’ with the updated data in the request body. The server will then update the resource's data with ID 1 based on the provided data in the request body.

The response from the server, containing the updated data, is then parsed as JSON and logged to the console.

{
  "id": 1,
  "title": "Hello freeCodeCamp",
  "body": "Welcome to freeCodeCamp",
  "userId": 1
}

Note: The PUT method is used to update data. The post of id 1 was updated.

How to Use the Post Method

The POST method is used to submit data to the server to create a new resource.

When you make a Post request, you ask the server to create a new resource with the data provided in the request body. The Post method is not considered "idempotent" or "safe," as making the same Post request multiple times may create multiple resources with different outcomes.

In JavaScript, you can use the Post method to send data to the server to create new resources. For example, you may use the Fetch API to make a Post request with new data to create a new user account on the server:

const newData = {
  title: "Hello freeCodeCamp",
  body: "Welcome to freeCodeCamp",
  userId: 1
};

fetch("https://jsonplaceholder.typicode.com/posts", {
  method: "POST",
  headers: {
    "Content-type": "application/json; charset=UTF-8"
  },
  body: JSON.stringify(newData)
})
  .then((response) => response.json())
  .then((data) => console.log(data))
  .catch((error) => console.error(error));

In this example, the Post request is made to the URL ‘https://jsonplaceholder.typicode.com/posts’ with the new data in the request body. The server will then create a new resource with the provided data, and the response from the server, containing the newly created resource data, is parsed as JSON and logged to the console.

{
  "title": "Hello freeCodeCamp",
  "body": "Welcome to freeCodeCamp",
  "userId": 1,
  "id": 101
}

Note: A new id of 101 is created because this is new data that does not exist before, so a unique ID is assigned to it.

Best Practices and Considerations

1. Use appropriate request methods: It's important to choose the appropriate one based on the intended operation on the server-side resource. Use Call for custom actions or functions, Put for updating existing resources, and Post for creating new ones.

2. Follow RESTful principles: If you're building a RESTful API, it's important to follow the principles of Representational State Transfer (REST), which includes using standard HTTP request methods for CRUD operations. Use Get for retrieving resource data, Put for updating, Post for creating new resources, and Delete for deleting resources.

3. Consider idempotency and safety: Put requests are idempotent, meaning making the same request multiple times will have the same outcome as making it once. Post requests are not idempotent, and making the same request multiple times may create multiple resources with different outcomes. Consider your operation's idempotency and safety requirements when choosing the appropriate request method.

Wrapping Up

HTTP is a crucial protocol that governs how data is transmitted and received between clients and servers on the World Wide Web. Request methods in HTTP, such as Call, Put, and Post, indicate the type of operation the client wants to perform on a resource on the server.

Understanding how these request methods work is essential in web development, as they determine how the server will handle the requests and what actions will be taken on the resources.

By utilizing the appropriate request methods in your web applications, you can effectively communicate with servers and manage resources reliably and efficiently.

Have fun coding!

Embark on a journey of learning! Browse 200+ expert articles on web development. Search 'request' for a deep dive into POST, GET, and making HTTP requests with React and JavaScript. Check out my blog for more captivating content from me.

There are various ways to design web applications, including GraphQL, SOAP, Falcor, gRPC, WebSockets, and Serverless Functions, with REST being the most popular (according to the 2021 State-of-API survey by Postman). And at the heart of all these architectures is HTTP.

What to Learn Along with HTTP

To understand HTTP, it is helpful to have a basic understanding of the following concepts:

1. Networking: Knowledge of how computers communicate with each other over networks is essential for understanding HTTP. This includes concepts such as IP addresses, DNS, and routing.
2. Web architecture: HTTP is a key part of web architecture, so understanding how web applications and websites are built can help you understand HTTP better. This includes concepts such as HTML, CSS, and JavaScript.
3. Server-side programming: HTTP is used to communicate between web browsers and servers, so understanding how servers work and how to build server-side applications can help you understand how HTTP works.
4. Client-side programming: HTTP is also used to communicate between web browsers and client-side applications, so understanding how to build client-side applications using JavaScript can also be helpful.

What to Expect in This Article

• How the HTTP protocol works.
• How to make network requests with Chrome and Postman.
• How to upload data with the HTTP POST method in Postman.

By the end of the article, readers should have a basic understanding of HTTP, as well as the tools and resources available for testing and troubleshooting applications.

Table of Contents

• Introduction to HTTP
• What is the HTTP Request-Response Cycle?
• How to Create HTTP Requests
• What is an HTTP Request URL?
• What Are HTTP Request Methods?
• What Are HTTP Request Headers?
• What is an HTTP Request Body?
• What is an HTTP Response?

Introduction to HTTP

HTTP (Hypertext Transfer Protocol) is a protocol used for exchanging information over the internet. HTTP is like the delivery system for information on the internet. It makes sure information goes from one place to another, like how ships carry goods across the ocean. It's the foundation of the World Wide Web.

HTTP is what makes the internet work. It's a way for web browsers and servers to talk to each other and send things like web pages back and forth. It's important for people who build websites and web applications to know how it works.

Without HTTP, it would be difficult to imagine how the internet would work. There would be no web pages, no URLs, and no hyperlinks. Instead, users would need to know the exact IP address of the server hosting the information they want to access, and they would need to use a low-level protocol like TCP/IP to transfer data.

What is the HTTP Request-Response Cycle?

Communication in HTTP centers around a concept called the Request-Response Cycle.

The request-response cycle is the process by which a client (such as a web browser or a mobile app) communicates with a server to retrieve resources or perform actions. The cycle involves several steps:

1. The client initiates a request to the server by sending an HTTP request message, which contains information such as the requested resource and any additional parameters.
2. The server receives the request message and processes it, using its resources to generate a response message.
3. The server sends the response message back to the client, which typically contains the requested resource (such as a web page) and any additional information or metadata.
4. The client receives the response message and processes it, usually by rendering the content in a web browser or displaying it in an app.
5. The client may initiate additional requests to the server, repeating the cycle as needed.

How to Create HTTP Requests

To create a valid HTTP request, you need the following:

• A URL.
• The HTTP method.
• A list of headers (request headers).
• The request body.

Here's an example of an HTTP request header, with three lines:

GET /watch?v=8PoQpnlBXD0 HTTP/1.1
Host: www.youtube.com
Cookie: GPS=1; VISITOR_INFO1_LIVE=kOe2UTUyPmw; YSC=Jt6s9YVWMd4

1. The first line specifies the HTTP method, path, and protocol version. In this case, it is a GET request for the video located at the path /watch?v=8PoQpnlBXD0 using the HTTP/1.1 protocol.
2. The second line specifies the host of the website, which is www.youtube.com.
3. The third line contains a cookie header, which is used for sending and storing small pieces of data on the client side. In this case, the cookie header contains three values: GPS=1, VISITOR_INFO1_LIVE=kOe2UTUyPmw, and YSC=Jt6s9YVWMd4. These values can be used by YouTube to track and personalize the user's experience.

What is an HTTP Request URL?

When a web browser attempts to access an image on the internet, it sends a request to the server using a URL. This URL is unique and points to a specific resource on the server.

A resource can be anything that has a name and can be accessed with a unique identifier like a user, product, article, document, or image. You can think of resources as nouns.

What Are HTTP Request Methods?

The request method tells the server what kind of action the client wants the server to take. The most common methods are:

What Are HTTP Request Headers?

HTTP request headers are additional pieces of information that are sent by the client as part of an HTTP request. They have a name/value format. That is:

Name: Value

These headers provide context and additional instructions to the server, which can be used to process the request or customize the response.

Here's an example of an HTTP request header:

GET /api/data HTTP/1.1
Host: example.com
User-Agent: Mozilla/5.0 (Windows NT 10.0; Win64; x64) AppleWebKit/537.36 (KHTML, like Gecko) Chrome/89.0.4389.82 Safari/537.36
Accept: application/json
Accept-Language: en-US,en;q=0.5
Authorization: Token abc123
Cache-Control: no-cache
Connection: keep-alive
Referer: https://www.google.com/
Pragma: no-cache

In this example, the GET method is used to send a request to the /api/data endpoint on the example.com server using HTTP/1.1 protocol. The request includes ten headers:

What is an HTTP Request Body?

In HTTP, the request body is the data that is sent from the client to the server as part of an HTTP request. The example below shows how to upload an image to the Cat API Server:

And here's what the request looks like:

POST /v1/images/upload HTTP/1.1
Host: api.thecatapi.com
x-api-key: API_KEY
Content-Length: 232
Content-Type: multipart/form-data; boundary=----WebKitFormBoundary7MA4YWxkTrZu0gW

------WebKitFormBoundary7MA4YWxkTrZu0gW
Content-Disposition: form-data; name="file"; filename="/C:/Users/USER/Downloads/cat1.jpg"
Content-Type: image/jpeg

(data)
------WebKitFormBoundary7MA4YWxkTrZu0gW--

The request includes these headers:

1. Host: This header specifies the hostname of the server that the client is trying to connect to.
2. Content-Type: The request is uploading an image file named cat1.jpg using a type of data called multipart/form-data. The image is in JPEG format and its content is included in the request body.
3. x-api-key: This header provides an API key for authentication purposes.
4. Content-Length: This header specifies the length of the request body in bytes. The value of this field is 232.

When the server receives this request, it will parse the request body and use it to create a new entry in the Cat API database. The server will then return a response that includes information about the new entry, such as the image URL and the database ID.

What is an HTTP Response?

An HTTP response is the message that a server sends back to a client in response to an HTTP request. It usually consists of a status line, headers, and a message body:

HTTP/1.1 200 OK
Date: Sun, 28 Mar 2023 10:15:00 GMT
Content-Type: application/json
Server: Apache/2.4.39 (Unix) OpenSSL/1.1.1c PHP/7.3.6
Content-Length: 1024

{
    "name": "John Doe",
    "email": "johndoe@example.com",
    "age": 30,
    "address": {
        "street": "123 Main St",
        "city": "Anytown",
        "state": "CA",
        "zip": "12345"
    }
}

The status line contains the HTTP version, a status code indicating the outcome of the request, and a corresponding message.

The headers provide additional information about the response, such as the content type of the message body or the date and time that the response was sent.

The message body contains the actual response data, such as HTML, JSON, or XML content.

Some common HTTP status codes include:

Here's an example of a JSON response from the Cat API:

{
    "id": "ErDd1JRRT",
    "url": "https://cdn2.thecatapi.com/images/ErDd1JRRT.jpg",
    "width": 4282,
    "height": 6424,
    "original_filename": "cat1.jpg",
    "pending": 0,
    "approved": 1
}

This is a JSON response from a Cat API request that appears to provide metadata about an image that has been uploaded or retrieved from the API. Here's what each field means:

• id: A unique identifier for the image.
• url: The URL where the image can be accessed.
• width: The width of the image in pixels.
• height: The height of the image in pixels.
• original_filename: The original name of the file that was uploaded.
• pending: A flag indicating whether the image is still being processed by the API.
• approved: A flag indicating whether the image has been approved for public use by the API.

Conclusion

HTTP (Hypertext Transfer Protocol) is a protocol used for exchanging information over the internet. It forms the foundation of the World Wide Web and allows communication between web browsers and servers.

This article is a short introduction to HTTP. If you are interested in learning more, check out these textbook recommendations:

• "HTTP: The Definitive Guide" by David Gourley and Brian Totty - This book is widely regarded as the authoritative guide to HTTP. It covers the protocol in-depth and provides detailed information on its features and implementation.
• "HTTP Pocket Reference" by Clinton Wong - This book provides a concise and portable reference to the HTTP protocol. It covers the essentials of the protocol and is a great resource for developers who need quick access to HTTP information.
• "Web Performance Daybook Volume 2: Techniques and Tips for Optimizing Web Site Performance" edited by Stoyan Stefanov - This book is a collection of essays and articles on web performance, including a section on HTTP optimization. It provides practical advice on how to optimize HTTP for faster and more efficient web performance.

All the code samples for this course are in JavaScript, but the networking concepts you'll learn here apply generally to all coding languages. If you're not familiar with JavaScript yet, you can check out my JS course here.

I've included all the learning material you'll need here in this article, but if you would like a more hands-on experience, you can take the interactive version of this course with coding challenges on Boot.dev here.

I've also published a free video version of this course on the freeCodeCamp YouTube channel:

If you like this video, you can check out my other tutorials on my Boot.dev YouTube channel here.

All that said, let's jump into learning about HTTP!

Table of Contents

1. Why HTTP?

2. What is DNS?

3. What Are URIs?

4. Async/Await

5. Error Handling

6. HTTP Headers

7. What is JSON?

8. HTTP Methods

9. URL Paths and Parameters

10. What is HTTPs?

Why HTTP?

Communicating on the web

Instagram would be pretty terrible if you had to manually copy your photos to your friend's phone when you wanted to share them. Modern applications need to be able to communicate information between devices over the internet.

• Gmail doesn't just store your emails in variables on your computer, it stores them on computers in their data centers.

• You don't lose your Slack messages if you drop your computer in a lake – those messages exist on Slack's servers.

How does web communication work?

When two computers communicate with each other, they need to use the same rules. An English speaker can't communicate verbally with a Japanese speaker, and similarly, two computers need to speak the same language to communicate.

This "language" that computers use is called a protocol. The most popular protocol for web communication is HTTP, which stands for Hypertext Transfer Protocol.

Interacting with a server

In this course, a lot of the code samples will interact with the PokeAPI. It serves data about Pokémon.

Here's some code that retrieves a list of Pokémon from the PokeAPI:

const pokemonResp = await getItemData()

logPokemons(pokemonResp.results)

async function getItemData() {
  const response = await fetch('https://pokeapi.co/api/v2/pokemon/', {
    method: 'GET',
    mode: 'cors',
    headers: {
      'Content-Type': 'application/json'
    }
  })
  return response.json()
}

function logPokemons(pokemons) {
  for (const pokemon of pokemons) {
    console.log(pokemon.name)
  } 
}

When you run this code, you'll notice that none of the data that is logged to the console was generated within our code! That's because the data we retrieved is being sent over the internet from our servers via HTTP. Don't worry, we'll explain more about that later.

HTTP Requests and Responses

At the heart of HTTP is a simple request-response system. The "requesting" computer, also known as the "client", asks another computer for some information. That computer, the "server" sends back a response with the information that was requested.

We'll talk about the specifics of how the "requests" and "responses" are formatted later. For now, just think of it as a simple question-and-answer system.

• Request: "What are the items in the Fantasy Quest game?"

• Response: A list of the items in the Fantasy Quest game

HTTP powers websites

As we discussed, HTTP, or Hypertext Transfer Protocol, is a protocol designed to transfer information between computers.

There are other protocols for communicating over the internet, but HTTP is the most popular and is particularly great for websites and web applications.

Each time you visit a website, your browser is making an HTTP request to that website's server. The server responds with all the text, images, and styling information that your browser needs to render its pretty website.

HTTP URLs

A URL, or Uniform Resource Locator, is essentially the address of another computer, or "server" on the internet. Part of the URL specifies how to reach the server, and part of it tells the server what information we want - but more on that later.

For now, it's important to understand that a URL represents a piece of information on another computer that we want access to. We can get access to it by making a request, and reading the response that the server replies with.

How to Use URLs in HTTP

The http:// at the beginning of a website URL specifies that the http protocol will be used for communication.

Other communication protocols use URLs as well, (hence "Uniform Resource Locator"). That's why we need to be specific when we're making HTTP requests by prefixing the URL with http://

Requests and Responses Review

• A "client" is a computer making an HTTP request

• A "server" is a computer responding to an HTTP request

• A computer can be a client, a server, both, or neither. "Client" and "server" are just words we use to describe what computers are doing within a communication system.

• Clients send requests and receive responses

• Servers receive requests and send responses

JavaScript's Fetch API

In this course, we'll be using JavaScript's built-in fetch API to make HTTP requests.

The fetch() function is made available to us by the JavaScript language running in the browser. All we have to do is provide it with the parameters it requires.

How to Use Fetch

const response = await fetch(url, settings)
const responseData = await response.json()

We'll go in-depth on the various things happening in this standard fetch call later, but let's cover some basics for now.

• response is the data that comes back from the server

• url is the URL we are making a request to

• settings is an object containing some request-specific settings

• The await keyword tells JavaScript to wait until the request comes back from the server before continuing

• response.json() converts the response data from the server into a JavaScript object

See if you can spot the issue with this code snippet:

const pokemonResp = getItemData()

logPokemons(pokemonResp.results)

// the bug is above this line

async function getItemData() {
  const response = await fetch('https://pokeapi.co/api/v2/pokemon/', {
    method: 'GET',
    mode: 'cors',
    headers: {
      'Content-Type': 'application/json'
    }
  })
  return response.json()
}

function logPokemons(pokemons) {
  for (const pokemon of pokemons) {
    console.log(pokemon.name)
  } 
}

Hint: We're not waiting for the data to be sent back across the network.

Web Clients

A web client is a device making requests to a web server. A client can be any type of device but is often something users physically interact with. For example:

• A desktop computer

• A mobile phone

• A tablet

In a website or web application, we call the user's device the "front-end".
A front-end client makes requests to a back-end server.

Web Servers

Up to this point, most of the data you have worked with in your code has simply been generated and stored locally in variables.

While you'll always use variables to store and manipulate data while your program is running, most websites and apps use a web server to store, sort, and serve that data so that it sticks around for longer than a single session, and can be accessed by multiple devices.

Listening and serving data

Similar to how a server at a restaurant brings your food to the table, a web server) serves web resources, such as web pages, images, and other data. The server is turned on and "listening" for inbound requests constantly so that the second it receives a new request, it can send an appropriate response.

The server is the back-end

While the "front-end" of a website or web application is the device the user interacts with, the "back-end" is the server that keeps all the data housed in a central location. If you're still confused, check out this article comparing front-end and back-end development.

A server is just a computer

"Server" is just the name we give to a computer that is taking on the role of serving data across a network connection.

A good server is turned on and available 24 hours a day, 7 days a week. While your laptop can be used as a server, it makes more sense to use a computer in a data center that's designed to be up and running constantly.

What is DNS?

Web Addresses

In the real world, we use addresses to help us find where a friend lives, where a business is located, or where a party is being thrown.

In computing, web clients find other computers over the internet using Internet Protocol or IP addresses.

An IP address is a numerical label that serves two main functions:

1. Location Addressing

2. Network Identification

Domain names and IP Addresses

Each device connected to the internet has a unique IP address. When we browse the internet, the domains we navigate to are all associated with a particular IP address.

For example, this Wikipedia URL points to a page about miniature pigs: https://en.wikipedia.org/wiki/Miniature_pig
The domain portion of the URL is en.wikipedia.org. en.wikipedia.org converts to a specific IP address, and that IP address tells your computer exactly where to communicate with that Wikipedia page.

Cloudflare is a tech company that provides a cool public HTTP server that we can use to look up the IP address of any domain. Take a look at this sample code:

async function fetchIPAddress(domain) {
  const resp = await fetch(`https://cloudflare-dns.com/dns-query?name=${domain}&type=A`, {
    headers: {
      'accept': 'application/dns-json'
    }
  })
  const respObject = await resp.json()
  for (const record of respObject.Answer) {
    return record.data
  }
  return null
}

const domain = 'api.boot.dev'
const ipAddress = await fetchIPAddress(domain)
if (!ipAddress) {
  console.log('something went wrong in fetchIPAddress')
} else {
  console.log(`found IP address for domain ${domain}: ${ipAddress}`)
}

To recap, a "domain name" is part of a URL. It's the part that tells the computer where the server is located on the internet by being converted into a numerical IP address.

We'll cover exactly how an IP address is used by your computer to find a path to the server in a later networking course. For now, it's just important to understand that an IP address is what your computer is using at a lower level to communicate on a network.

Deploying a real website to the internet is actually quite simple. It involves only a couple of steps:

1. Create a server that hosts your website files and connect it to the internet

2. Acquire a domain name

3. Connect the domain name to the IP address of your server

4. Your server is accessible via the internet!

As we discussed, the "domain name" or "hostname" is part of a URL. We'll get to the other parts of a URL later.

For example, the URL https://example.com/path has a hostname of example.com. The https:// and /path portions are not part of the domain name -> IP address mapping that we've been learning about.

Using the URL API in JavaScript

The URL API is built into JavaScript. You can create a new URL object like this:

const urlObj = new URL('https://example.com/example-path')

And then you can extract just the hostname:

const urlObj.hostname

DNS Review

So we've talked about domain names and what their purpose is, but we haven't talked about the system that's used to do that conversion.

DNS, or the "Domain Name System", is the phonebook of the internet. Humans connect to websites through domain names, like Boot.dev.

DNS "resolves" these domain names to find the associated IP addresses so that web clients can load the resources for the specific address.

How does DNS Work?

We'll go into more detail on DNS in a future course, but to give you a simplified idea of how it works, let's introduce ICANN. ICANN is a not-for-profit organization that manages DNS for the entire internet.

Whenever your computer attempts to resolve a domain name, it contacts one of ICANN's "root nameservers" whose address is included in your computer's networking configuration.

From there, that nameserver can gather the domain records for a specific domain name from their distributed DNS database.

If you think of DNS as a phonebook, ICANN is the publisher that keeps the phonebook in print and available.

Subdomains

We learned about how a domain name resolves to an IP address, which is just a computer on a network - often the internet.

A subdomain prefixes a domain name, allowing a domain to route network traffic to many different servers and resources.

For example, the Boot.dev website is hosted on a different computer than our blog. Our blog, found at blog.boot.dev is hosted on our "blog" subdomain.

What are URIs?

We briefly touched on URLs earlier, but now let's dive a little deeper into the subject.

A URI, or Uniform Resource Identifier, is a unique character sequence that identifies a resource that is (almost always) accessed via the internet.

Just like JavaScript has syntax rules, so do URIs. These rules help ensure uniformity so that any program can interpret the meaning of the URI in the same way.

URIs come in two main types:

• URLs

• URNs

We will focus specifically on URLs in this course, but it's important to know that URLs are only one kind of URI.

URLs have quite a few sections, some of which are required, others not.
Let's use the URL API to parse a URL and print all the different parts. We'll learn more about each part later, for now, let's just split and print a URL.

function printURLParts(urlString) {
  const urlObj = new URL(urlString)
  console.log(`protocol: ${urlObj.protocol}`)
  console.log(`username: ${urlObj.username}`)
  console.log(`password: ${urlObj.password}`)
  console.log(`hostname: ${urlObj.hostname}`)
  console.log(`port: ${urlObj.port}`)
  console.log(`pathname: ${urlObj.pathname}`)
  console.log(`search: ${urlObj.search}`)
  console.log(`hash: ${urlObj.hash}`)
}

const fantasyQuestURL = 'http://dragonslayer:pwn3d@fantasyquest.com:8080/maps?sort=rank#id'
printURLParts(fantasyQuestURL)

Further dissecting a URL

There are 8 main parts to a URL, though not all the sections are always present. Each piece plays a specific role in helping clients locate the specified resource.
The 8 sections are:

• The protocol is required

• Usernames and passwords are optional

• A domain is required

• The default port for a given protocol is used if one is not provided

• The default ( / ) path is used if one isn't provided

• A query is optional

• A fragment is optional

Don't get too hung up on memorizing this stuff

Because names for the different sections are often used interchangeably, and because not all the parts of the URL are always present, it can be hard to keep things straight.

Don't worry about memorizing this stuff! Try to just get familiar with these URL concepts from a high level. Like any good developer, you can just look it up again the next time you need to know more.

The Protocol

The "protocol", also referred to as the "scheme", is the first component of a URL. Its purpose is to define the rules by which the data being communicated is displayed, encoded, or formatted.

Some examples of different URL protocols:

• http

• ftp

• mailto

• https

For example:

• http://example.com

• mailto:noreply@fantasyquest.app

Not all schemes require a "//"

The "http" in a URL is always followed by ://. All URLs have the colon, but the // part is only included for schemes that have an authority component.

As you can see above, the mailto scheme doesn't use an authority component, so it doesn't need the slashes.

URL Ports

The port in a URL is a virtual point where network connections are made. Ports are managed by a computer's operating system and are numbered from 0 to 65,535.

Whenever you connect to another computer over a network, you're connecting to a specific port on that computer, which is being listened to by a specific piece of software on that computer. A port can only be used by one program at a time, which is why there are so many possible ports.

The port component of a URL is often not visible when browsing normal sites on the internet, because 99% of the time you're using the default ports for the HTTP and HTTPS schemes: 80 and 443, respectively.

Whenever you aren't using a default port, you need to specify it in the URL. For example, port 8080 is often used by web developers when they're running their server in "test mode" so that they don't use the "production" port "80".

URL Paths

In the early days of the internet, a URL's path often was a reflection of the file path on the server to the resource the client was requesting.

For example, if the website https://exampleblog.com had a web server running within its /home directory, then a request to the https://exampleblog.com/site/index.html URL might expect the index.html file from within the /home/site directory to be returned.

Websites used to be very simple. They were just a collection of text documents stored on a server. A simple piece of server software could handle incoming HTTP requests and respond with the documents according to the path component of the URLs.

These days, it's not always about the filesystem

On many modern web servers, a URL's path isn't a reflection of the server's filesystem hierarchy. Paths in URLs are essentially just another type of parameter that can be passed to the server when making a request.

Conventionally, two different URL paths should denote different resources. For example, different pages on a website, or maybe different data types from a game server.

Query parameters

Query parameters in a URL are not always present. In the context of websites, query parameters are often used for marketing analytics or for changing a variable on the web page. With website URLs, query parameters rarely change which page you're viewing, though they often will change the page's contents.

That said, query parameters can be used for anything the server chooses to use them for, just like the URL's path.

How Google uses query parameters

1. Open a new tab and go to google.com

2. Search for "hello world"

3. Take a look at your current URL. It should start with https://www.google.com/search?q=hello+world

4. Change the URL to say https://www.google.com/search?q=hello+universe

5. Press "enter"

You should see new search results for the query "hello universe". Google chose to use query parameters to represent the value of your search query. It makes sense - each search result page is essentially the same page as far as structure and formatting are concerned - it's just showing you different results based on the search query.

Async/Await

You're probably already familiar with synchronous code, which means code that runs in sequence. Each line of code executes in order, one after the next.

Example of synchronous code:

console.log("I print first");
console.log("I print second");
console.log("I print third");

Asynchronous or async code runs in parallel. That means code further down runs at the same time that a previous line of code is still running. A good way to visualize this is with the JavaScript function setTimeout().

setTimeout accepts a function and a number of milliseconds as inputs. It waits until the number of milliseconds has elapsed, and then it executes the function it was given.

Example of asynchronous code:

jsconsole.log("I print first");
setTimeout(() => console.log("I print third because I'm waiting 100 milliseconds"), 100);
console.log("I print second");

Try altering the waiting times in the async code below to get the messages to print in the proper order:

const craftingCompleteWait = 0
const combiningMaterialsWait = 0
const smeltingIronBarsWait = 0
const shapingIronWait = 0

// Don't touch below this line

setTimeout(() => console.log('Iron Longsword Complete!'), craftingCompleteWait)
setTimeout(() => console.log('Combining Materials...'), combiningMaterialsWait)
setTimeout(() => console.log('Smelting Iron Bars...'), smeltingIronBarsWait)
setTimeout(() => console.log('Shaping Iron...'), shapingIronWait)

console.log('Firing up the forge...')

await sleep(2500)
function sleep(ms) {
  return new Promise((resolve) => setTimeout(resolve, ms))
}

Expected order:

1. Firing up the forge..

2. Smelting Iron Bars...

3. Combining Materials...

4. Shaping Iron...

5. Iron Longsword Complete!

Why do we want async code?

We try to keep most of our code synchronous because it's easier to understand, and therefore often has fewer bugs. But sometimes we need our code to be asynchronous.

For example, whenever you update your user settings on a website, your browser will need to communicate those new settings to the server. The time it takes your HTTP request to physically travel across all the wiring of the internet is usually around 100 milliseconds. It would be a very poor experience if your webpage were to freeze while waiting for the network request to finish. You wouldn't even be able to move the mouse while waiting!

By making network requests asynchronously, we let the webpage execute other code while waiting for the HTTP response to come back. This keeps the user experience snappy and user-friendly.

As a general rule, we should only use async code when we need to for performance reasons. Synchronous code is simpler.

Promises in JavaScript

A Promise in JavaScript is very similar to making a promise in the real world. When we make a promise, we are making a commitment to something.

For example, I promise to explain JavaScript promises to you. My promise to you has 2 potential outcomes: it is either fulfilled, meaning I eventually explained promises to you, or it is rejected, meaning I failed to keep my promise and didn't explain promises.

The Promise Object represents the eventual fulfillment or rejection of our promise and holds the resulting values. In the meantime, while we're waiting for the promise to be fulfilled, our code continues executing.

Promises are the most popular modern way to write asynchronous code in JavaScript.

How to Declare a Promise

Here is an example of a promise that will resolve and return the string "resolved!" or reject and return the string "rejected!" after 1 second.

const promise = new Promise((resolve, reject) => {
  setTimeout(() => {
    if (getRandomBool()) {
      resolve("resolved!")
    } else {
      reject("rejected!")
    }
  }, 1000)
})

function getRandomBool(){
  return Math.random() < .5
}

How to Use a Promise

Now that we've created a promise, how do we use it?

The Promise object has .then and .catch that make it easy to work with. Think of .then as the expected follow-up to a promise, and .catch as the "something went wrong" follow-up.

If a promise resolves, its .then function will execute. If the promise rejects, its .catch method will execute.

Here's an example of using .then and .catch with the promise we made above:

promise.then((message) => {
    console.log(`The promise finally ${message}`)
}).catch((message) => {
    console.log(`The promise finally ${message}`)
})

// prints:
// The promise finally resolved!
// or
// the promise finally rejected!

Why are Promises useful?

Promises are the cleanest (but not the only) way to handle the common scenario where we need to make requests to a server, which is typically done via an HTTP request. In fact, the fetch() function we were using earlier in the course returns a promise!

I/O, or "input/output"

Almost every time you use a promise in JavaScript it will be to handle some form of I/O. I/O, or input/output, refers to when our code needs to interact with systems outside of the (relatively) simple world of local variables and functions.
Common examples of I/O include:

• HTTP requests

• Reading files from the hard drive

• Interacting with a Bluetooth device

Promises help us perform I/O without forcing our entire program to freeze up while we wait for a response.

Promises and the "await" keyword

We have used the await keyword a few times in this course, so it's time we finally understand what's going on under the hood.

The await keyword is used to wait for a promise to resolve. Once it has been resolved, the await expression returns the value of the resolved Promise.

Example with .then callback

promise.then((message) => {
  console.log(`Resolved with ${message}`)
}).

Example of awaiting a promise

const message = await promise
console.log(`Resolved with ${message}`)

The async keyword

While the await keyword can be used in place of .then() to resolve a promise, the async keyword can be used in place of new promise() to create a new promise.

When a function is prefixed with the async keyword, it will automatically return a promise. That promise resolves with the value that your code returns from the function. You can think of async as "wrapping" your function within a promise.

These are equivalent:

New Promise()

function getPromiseForUserData(){
  return new Promise((resolve) => {
    fetchDataFromServerAsync().then(function(user){
      resolve(user)
    })
  })
}

const promise = getPromiseForUserData()

Async

async function getPromiseForUserData(){
  const user = await fetchDataFromServer()
  return user
}

const promise = getPromiseForUserData()

.then() vs await

In the early days of web browsers, promises and the await keyword didn't exist, so the only way to do something asynchronously was to use callbacks.

A "callback function" is a function that you hand to another function. That function then calls your callback later on. The setTimeout function we've used in the past is a good example.

function callbackFunction(){
  console.log("calling back now!")
}
const milliseconds = 1000
setTimeout(callbackFunction, milliseconds)

While even the .then() syntax is generally easier to use than callbacks without the Promise API, the await syntax makes them even easier to use. You should use async and await over .then and new Promise() as a general rule.

To demonstrate, which of these is easier to understand?

fetchUser.then(function(user){
  return fetchLocationForUser(user)
}).then(function(location){
  return fetchServerForLocation(location)
}).then(function(server){
  console.log(`The server is ${server}`)
});

const user = await fetchUser()
const location = await fetchLocationForUser(user)
const server = await fetchServerForLocation(location)
console.log(`The server is ${server}`)

They both do the same thing, but the second example is so much easier to understand! The async and await keywords weren't released until after the .then API, which is why there is still a lot of legacy .then() code out there.

Error Handling

When something goes wrong while a program is running, JavaScript uses the try/catch paradigm for handling those errors. Try/catch is fairly common, and Python uses a similar mechanism.

First, an error is thrown

For example, let's say we try to access a property on an undefined variable. JavaScript will automatically "throw" an error.

const speed = car.speed
// The code crashes with the following error:
// "ReferenceError: car is not defined"

Trying and catching errors

By wrapping that code in a try/catch block, we can handle the case where car is not yet defined.

try {
  const speed = car.speed
} catch (err) {
  console.log(`An error was thrown: ${err}`)
  // the code cleanly logs:
  // "An error was thrown: ReferenceError: car is not defined"
}

Bugs vs Errors

Error handling via try/catch is not the same as debugging. Likewise, errors are not the same as bugs.

• Good code with no bugs can still produce errors that are gracefully handled

• Bugs are, by definition, bits of code that aren't working as intended

What is Debugging?

"Debugging" a program is the process of going through your code to find where it is not behaving as expected. Debugging is a manual process performed by the developer.

Examples of debugging:

• Adding a missing parameter to a function call

• Updating a broken URL that an HTTP call was trying to reach

• Fixing a date-picker component in an app that wasn't displaying properly

What is Error Handling?

"Error handling" is code that can handle expected edge cases in your program. Error handling is an automated process that we design into our production code to protect it from things like weak internet connections, bad user input, or bugs in other people's code that we have to interface with.

Examples of error handling:

• Using a try/catch block to detect an issue with user input

• Using a try/catch block to gracefully fail when no internet connection is available

In short, don't use try/catch to try to handle bugs

If your code has a bug, try/catch won't help you. You need to just go find the bug and fix it.

If something out of your control can produce issues in your code, you should use try/catch or other error-handling logic to deal with it.

For example, there could be a prompt in a game for users to type in a new character name, but we don't want them to use punctuation. Validating their input and displaying an error message if something is wrong with it would be a form of "error handling".

async/await makes error handling easier

try and catch are the standard way to handle errors in JavaScript, the trouble is, the original Promise API with .then didn't allow us to make use of try and catch blocks.

Luckily, the async and await keywords do allow it - yet another reason to prefer the newer syntax.

.catch() callback on promises

The .catch() method works similarly to the .then() method, but it fires when a promise is rejected instead of resolved.

Example with .then and .catch callbacks

fetchUser().then(function(user){
  console.log(`user fetched: ${user}`)
}).catch(function(err){
  console.log(`an error was thrown: ${err}`)
});

Example of awaiting a promise

try {
  const user = await fetchUser()
  console.log(`user fetched: ${user}`)
} catch (err) {
  console.log(`an error was thrown: ${err}`)
}

As you can see, the async/await version looks just like normal try/catch JavaScript.

HTTP Headers

An HTTP header allows clients and servers to pass additional information with each request or response. Headers are just case-insensitive key-value pairs that pass additional metadata about the request or response.

HTTP requests from a web browser carry with them many headers, including but not limited to:

• The type of client (for example Google Chrome)

• The Operating system (for example Windows)

• The preferred language (for example US English)

As developers, we can also define custom headers in each request.

Headers API

The Headers API allows us to perform various actions on our request and response headers such as retrieving, setting, and removing them. We can access the headers object through the Request.headers and Response.headers properties.

How to Use the Browser's Developer Tools

Modern web browsers offer developers a powerful set of developer tools. The Developer Tools are a front-end web developer's best friend. For example, using the dev tools you can:

• View the web page's JavaScript console output

• Inspect the page's HTML, CSS, and JavaScript code

• View network requests and responses, along with their headers

The method for accessing dev tools varies from browser to browser. If you're on Chrome, you can just right-click anywhere within a web page and click the "inspect" option. Follow this link for more info on how to access dev tools.

The network tab

While all of the tabs within the dev tools are very useful, we will be focusing specifically on the Network tab in this chapter so we can play with HTTP headers.

The Network tab monitors your browser's network activity and records all of the requests and responses the browser is making, including how long each of those requests and responses takes to fully process.

If you navigate to the Network tab and don't see any requests appear, try refreshing the page.

Why are headers useful?

Headers are useful for several reasons, from design to security. But most often headers are used as metadata or data about the request.

So, for example, let's say we wanted to ask for a player's level from a game's server. We need to send that player's ID to the server so it knows which player to send back the information for. That ID is my request, it's not information about my request.

A good example of a use case for headers is authentication. Often times a user's credentials are included in request headers. Credentials don't have much to do with the request itself, but simply authorize the requester to be allowed to make the request in question.

What is JSON?

JavaScript Object Notation, or JSON, is a standard for representing structured data based on JavaScript's object syntax.

JSON is commonly used to transmit data in web apps using HTTP. The HTTP fetch() requests we have been using in this course have been returning data as JSON data.

JSON Syntax

Because we already understand what JavaScript objects look like, understanding JSON is easy. JSON is just a stringified JavaScript object. The following is valid JSON data:

{
    "movies": [
        {
            "id": 1,
            "genre": "Action",
            "title": "Iron Man",
            "director": "Jon Favreau"
        },
        {
            "id": 2,
            "genre": "Action",
            "title": "The Avengers",
            "director": "Joss Whedon"
        }
    ]
}

How to Parse HTTP Responses as JSON

JavaScript provides us with some easy tools to help us work with JSON. After making an HTTP request with the fetch() API, we get a Response object. That response object offers us some methods that help us interact with the response.

One such method is the .json() method. The .json() method takes the response stream returned by a fetch request and returns a Promise that resolves into a JavaScript object parsed from the JSON body of the HTTP response.

const resp = await fetch(...)
const javascriptObjectResponse = await resp.json()

It's important to note that the result of the .json() method is NOT JSON. It is the result of taking JSON data from the HTTP response body and parsing that input into a JavaScript Object.

JSON Review

JSON is a stringified representation of a JavaScript object, which makes it perfect for saving to a file or sending in an HTTP request.

Remember, an actual JavaScript object is something that exists only within your program's variables. If we want to send an object outside our program, for example, across the internet in an HTTP request, we need to convert it to JSON first.

It's not just used in JavaScript

Just because JSON is called JavaScript Object Notation doesn't mean it's only used by JavaScript! JSON is a common standard that is recognized and supported by every major programming language.

For example, even though Boot.dev's backend API is written in Go, we still use JSON as the communication format between the front-end and backend.

By the way, this course has been about interacting with back-end servers from a front-end perspective. But if you're curious about how you can become a back-end engineer, check out this guide I've put together. For reference, it takes most people between 6-18 months to learn enough to get their first back-end job.

Common JSON use-cases

• In HTTP request and response bodies

• As formats for text files. .json files are often used as configuration files.

• In NoSQL databases like MongoDB, ElasticSearch, and Firestore

How to Pronounce JSON

I pronounce it "Jay-sawn", but I've also heard people pronounce it "Jason", like the name.

How to Send JSON

JSON isn't just something we get from the server, we can also send JSON data.
In JavaScript, two of the main methods we have access to are JSON.parse(), and JSON.stringify().

JSON.stringify()

JSON.stringify() is particularly useful for sending JSON.

As you may expect, the JSON stringify() method does the opposite of parse. It takes a JavaScript object or value as input and converts it into a string. This is useful when we need to serialize the objects into strings to send them to our server or store them in a database.

Here's a snippet of code that sends a JSON payload to a remote server:

async function sendPayload(data, headers) {
  const response = await fetch(url, {
    method: 'POST',
    mode: 'cors',
    headers: headers,
    body: JSON.stringify(data)
  })
  return response.json()
}

How to Parse JSON

The JSON.parse() method takes a JSON string as input and constructs the JavaScript value/object described by the string. This allows us to work with the JSON as a normal JavaScript object.

Seeing as JSON objects have a tree-like structure, it can be helpful to know how to traverse them recursively if needs be.

const json = '{"title": "Avengers Endgame", "Rating":4.7, "inTheaters":false}';
const obj = JSON.parse(json)

console.log(obj.title)
// Avengers Endgame

XML

We can't talk about JSON without mentioning XML. Extensible Markup Language, or XML is a text-based format for representing structured information, just like JSON - it just looks a bit different.

XML is a markup language like HTML, but it's more generalized in that it does not use predefined tags. Just like how in a JSON object keys can be called anything, XML tags can also have any name.

<root>
  <id>1</id>
  <genre>Action</genre>
  <title>Iron Man</title>
  <director>Jon Favreau</director>
</root>

The same data in JSON form:

{
  "id": "1",
  "genre": "Action",
  "title": "Iron Man",
  "director": "Jon Favreau"
}

Why use XML?

XML and JSON both accomplish similar tasks, so which should you use?

XML used to be used for the same things that today JSON is used for. Configuration files, HTTP bodies, and other data-transfer use cases can work just fine using JSON or XML. Here's my advice: generally speaking, if JSON works, you should favor it over XML these days. JSON is lighter-weight, easier to read, and has better support in most modern programming languages.

There are some cases where XML might still be the better, or maybe even the necessary choice, but those cases will be rare.

HTTP Methods

HTTP defines a set of methods that we use every time we make a request. We have used some of these methods in previous exercises, but it's time we dive into them and understand the differences and use cases behind the different methods.

The GET method

The GET method is used to "get" a representation of a specified resource. You are not taking the data away from the server, but rather getting a representation, or copy, of the resource in its current state.

A get request is considered a safe method to call multiple times because it doesn't alter the state of the server.

How to Make a GET Request using the Fetch API

The fetch() method accepts an optional init object parameter as its second argument that we can use to define things like:

• method: The HTTP method of the request, like GET.

• headers: The headers to send.

• mode: Used for security, we'll talk about this in future courses

• body: The body of the request. Often encoded as JSON.

Example GET request using fetch:

await fetch(url, {
  method: 'GET',
  mode: 'cors',
  headers: {
    'sec-ch-ua-platform': 'macOS'
  }
})

Why do we use HTTP methods?

As we touched on before, the primary purpose of HTTP methods is to indicate to the server what we want to do with the resource we're trying to interact with.

At the end of the day, an HTTP method is just a string, like GET, POST, PUT, or DELETE. But by convention, backend developers almost always write their server code so that the methods correspond with different "CRUD" actions.

The "CRUD" actions are:

• Create

• Read

• Update

• Delete

The bulk of the logic in most web applications is "CRUD" logic. The web interface allows users to create, read, update and delete various resources.

Think of a social media site - users are basically creating, reading, updating and deleting their social posts. They are also creating, reading, updating and deleting their user accounts. It's CRUD all the way down!

As it happens, the 4 most common HTTP methods map nicely to the CRUD actions:

• POST = create

• GET = read

• PUT = update

• DELETE = delete

POST Requests

An HTTP POST request sends data to a server, typically to create a new resource. The body of the request is the payload that is being sent to the server with the request. Its type is indicated by the Content-Type header.

How to Add a body

The body of the request is the payload that is being sent to the server with the request. Its type is indicated by the Content-Type header - for us, that's going to be JSON.

POST requests are generally not safe methods to call multiple times, because it alters the state of the server. You wouldn't want to accidentally create 2 accounts for the same user, for example.

await fetch(url, {
  method: 'POST',
  mode: 'cors',
  headers: {
    'Content-Type': 'application/json'
  },
  body: JSON.stringify(data)
})

HTTP Status Codes

Now that we understand how to write HTTP requests from scratch, we need to learn how to ensure that the server is doing what we want.

Earlier in the course, we learned about how to access the browser's developer tools and use those tools to inspect HTTP requests. We can use that same process to check on the requests we are making and verify what they are doing so we can address potential problems.

When looking at requests, we can check on the Status Code of the request to get some information if the request was successful or not.

• 100-199: Informational responses. These are very rare.

• 200-299: Successful responses. Hopefully, most responses are 200's!

• 300-399: Redirection messages. These are typically invisible because the browser or HTTP client will automatically do the redirect.

• 400-499: Client errors. You'll see these often, especially when trying to debug a client application

• 500-599: Server errors. You'll see these sometimes, usually only if there is a bug on the server.

Here are some of the most common status codes, but you can see a full list here if you're interested.

• 200 - OK. This is by far the most common code, it just means that everything worked as expected.

• 201 - Created. This means that a resource was created successfully. Typically in response to a POST request.

• 301 - Moved permanently. This means the resource was moved to a new place, and the response will include where that new place is. Websites often use 301 redirects when they change their domain name, for example.

• 400 - Bad request. A general error indicating the client made a mistake in their request.

• 403 - Unauthorized. This means the client doesn't have the correct permissions. Maybe they didn't include a required authorization header, for example.

• 404 - Not found. You'll see this on websites quite often. It just means the resource doesn't exist.

• 500 - Internal server error. This means something went wrong on the server, likely a bug on their end.

You don't need to memorize them

You need to know the basics, like "2XX is good", "4XX is a client error", and "5XX is a server error". That said, you don't need to memorize all the codes, they're easy to look up.

Let's check some status codes!

The .status property on a Response object will give you the code. Here's an example:

async function getStatusCode(url, headers) {
  const response = await fetch(url, {
    method: 'GET',
    mode: 'cors',
    headers: headers
  })
  return response.status
}

PUT Method

The HTTP PUT method creates a new resource or replaces a representation of the target resource with the contents of the request's body. In short, it updates a resource's properties.

await fetch(url, {
   method: 'PUT',
   mode: 'cors',
   headers: {
   'Content-Type': 'application/json'
   },
   body: JSON.stringify(data)
})

POST vs PUT

You may be thinking PUT is similar to POST or PATCH, and frankly, you'd be right. The main difference is that PUT is meant to be idempotent, meaning multiple identical PUT requests should have the same effect on the server.

In contrast, several identical POST requests would have additional side effects, such as creating multiple copies of the resource.

HTTP Patch vs PUT

You may encounter PATCH methods from time to time. While it is not nearly as common as the other methods, like PUT, it's important to know about it and what it does. The PATCH method is intended to partially modify a resource.

Long story short, PATCH isn't nearly as popular as PUT, and many servers, even if they allow partial updates, will still just use the PUT method for that.

HTTP Delete

The DELETE method does exactly as you would expect: it's conventionally used to delete a specified resource.

// This deletes the location with ID: 52fdfc07-2182-454f-963f-5f0f9a621d72
const url = 'https://example-api.com/locations/52fdfc07-2182-454f-963f-5f0f9a621d72'

await fetch(url, {
  method: 'DELETE',
  mode: 'cors'
})

URL Paths and Parameters

The URL Path comes right after the domain (or port if one is provided) in a URL string.

In this URL, the path is /root/next: http://testdomain.com/root/next.

What paths meant in the early internet

In the early days of the internet, and sometimes still today, many web servers simply served raw files from the server's file system.

For example, if I wanted you to be able to access some text documents, I could start a web server in my documents directory. If you made a request to my server, you would be able to access different documents by using the path that matched my local file structure.

If I had a file in my local /documents/hello.txt, you could access it by making a GET request to http://example.com/documents/hello.txt.

How paths are used today

Most modern web servers don't use that simple mapping of URL path -> file path. Technically, a URL path is just a string that the web server can do what it wants with, and modern websites take advantage of that flexibility.

Some common examples of what paths are used for include:

• The hierarchy of pages on a website, whether or not that reflects a server's file structure

• Parameters being passed into an HTTP request, like an ID of a resource

• The version of the API

• The type of resource being requested

RESTful APIs

Representational State Transfer, or REST, is a popular convention that HTTP servers follow. Not all HTTP APIs are "REST APIs", or "RESTful", but it is very common.

RESTful servers follow a loose set of rules that makes it easy to build reliable and predictable web APIs. REST is more or less a set of conventions about how HTTP should be used.

Separate and agnostic

The big idea behind REST is that resources are transferred via well-recognized, language-agnostic client/server interactions.

A RESTful style means the implementation of the client and server can be done independently of one another, as long as some simple standards, like the names of the available resources, have been established.

Stateless

A RESTful architecture is stateless. This means that the server does not need to know what state the client is in, nor does the client need to know what state the server is in.

Statelessness in REST is enforced by interacting with resources instead of commands. Keep in mind, this doesn't mean the applications are stateless - on the contrary, what would "updating a resource" even mean if the server wasn't keeping track of its state?

Paths in REST

In a RESTful API, the last section of the path of a URL should specify which resource is being accessed. Then, as we talked about in the "methods" section, depending on whether the request is a GET, POST, PUT or DELETE, the resource is read, created, updated, or deleted.

For example, in the PokeAPI:

• https://pokeapi.co/api/v2/pokemon/

• https://pokeapi.co/api/v2/location/

The first part of the path specifies that we're interacting with an API rather than a website. The next part specifies the version, in this case, version 2, or v2.

Finally, the last part denotes which resource is being accessed, be it a location or pokemon.

URL Query Parameters

A URL's query parameters appear next in the URL structure but are not always present - they're optional. For example:

https://www.google.com/search?q=boot.dev

q=boot.dev is a query parameter. Like headers, query parameters are key / value pairs. In this case, q is the key and boot.dev is the value.

The Documentation of an HTTP Server

You may be wondering:

How the heck am I supposed to memorize how all these different servers work???

The good news is that you don't need to. When you work with a backend server, it's the responsibility of that server's developers to provide you with instructions, or documentation that explains how to interact with it.

For example, the documentation should tell you:

• The domain of the server

• The resources you can interact with (HTTP paths)

• The supported query parameters

• The supported HTTP methods

• Anything else you'll need to know to work with the server

The server has control

As we mentioned earlier, the server has complete control over how the path in a URL is interpreted and used in a request. The same goes for query parameters.

Not all servers support query parameters for every type of request, it just depends, so you'll need to consult the docs.

Multiple Query Parameters

We mentioned that query parameters are key/value pairs - that means we can have multiple pairs.

http://example.com?firstName=lane&lastName=wagner

In the example above:

• firstName = lane

• lastName = wagner

The ? separates the query parameters from the rest of the URL. The & is then used to separate every pair of query parameters after that.

For example, make this request to limit the number of Pokémon returned from the PokeAPI to 2:

https://pokeapi.co/api/v2/location/?limit=2

What is HTTPs?

Hypertext Transfer Protocol Secure or HTTPS is an extension of the HTTP protocol. HTTPS secures the data transfer between client and server by encrypting all of the communication.

HTTPS allows a client to safely share sensitive information with the server through an HTTP request, such as credit card information, passwords, or bank account numbers.

HTTPS requires that the client use SSL or TLS to protect requests and traffic by encrypting the information in the request. HTTPS is just HTTP with extra security.

HTTP vs HTTPS

HTTPS keeps your messages private, but not your identity

We won't cover how encryption works in this course, but we will in later courses. For now, it's important to note that while HTTPS encrypts what you are saying, it doesn't necessarily protect who you are. Tools like VPNs are needed for remaining anonymous online.

HTTPS ensures that you're talking to the right person (or server)

In addition to encrypting the information within a request, HTTPS uses digital signatures to prove that you're communicating with the server that you think you are.

If a hacker were to intercept an HTTPS request by tapping into a network cable, they wouldn't be able to successfully pretend they are your bank's web server.

Assuming that a server supports HTTPs, you use it by simply changing the protocol on your request URL: https://boot.dev

Want to put what you've learned into practice with a project?

Check out this project guide where you'll build a web crawler in JavaScript from scratch. It will have you using the Fetch API and parsing JSON data like a pro! You don't need to build the project, but it's a great way to practice what you're learned.

Congratulations on making it to the end!

If you're interested in doing the interactive coding assignments and quizzes for this course you can check out the Learn HTTP course over on Boot.dev.

This course is a part of my full back-end developer career path, made up of other courses and projects if you're interested in checking those out.

If you want to see the other content I'm creating related to web development, check out some of my links below:

• Lane on Twitter

• Lane on YouTube

• Lane's Personal Site

We just published a full course on the freeCodeCamp.org YouTube channel that will help you master the HTTP networking protocol by completing over 80 coding exercises and quizzes in JavaScript. The course is designed to help students understand the various concepts of HTTP networking through hands-on learning.

Lane Wagner created this course. He is a senior back end engineer and is the creator of boot.dev where he has published many interactive courses.

Starting from the basics, students watching this course will learn about:

• why HTTP is important,
• how DNS (Domain Name System) works,
• the difference between URIs (Uniform Resource Identifiers) and URLs (Uniform Resource Locators),
• how HTTP headers work,
• how to write and use JSON (JavaScript Object Notation),
• the difference between various HTTP methods,
• how URL paths are used in HTTP communication, and
• implementing security using HTTPS.

To help students put their knowledge into practice, the course includes a project where they will build a real web crawler using Node.js. The project will cover the following topics: setting up a development environment, creating a "Hello World" program, normalizing URLs, extracting URLs from HTML, using the Fetch API, recursively crawling the web, and printing an SEO report.

By the end of this video course, students will have a solid understanding of HTTP networking and will be able to put their skills into practice by building a real web crawler.

In conclusion, if you're looking to deepen your knowledge of HTTP networking and build practical skills, this video course is an excellent choice. With over 80 coding exercises and quizzes, students will get a hands-on learning experience that will help them understand the various concepts of HTTP networking. Sign up now and start your journey to mastering HTTP networking.

Watch the full course on the freeCodeCamp.org YouTube channel (5-hour watch).

One of the five popular HTTP methods for making requests and interacting with your servers is the POST method, which you can use to send data to a server.

In this article, you will learn the various methods that you can use to send an HTTP POST request to your back-end server in JavaScript. We'll send GET requests to the free JSON Placeholder todos API for this guide.

There are two built-in JavaScript methods for making an HTTP POST request that don't require the installation of a library or the use of a CDN. These methods are the FetchAPI, based on JavaScript promises, and XMLHttpRequest, based on callbacks.

There are other methods, such as Axios and jQuery, that you will also learn how to use.

How to Send a POST Request with the Fetch API

The FetchAPI is a built-in method that takes in one compulsory parameter: the endpoint (API URL). While the other parameters may not be necessary when making a GET request, they are very useful for the POST HTTP request.

The second parameter is used to define the body (data to be sent) and type of request to be sent, while the third parameter is the header that specifies the type of data you will send, for example JSON.

fetch("https://jsonplaceholder.typicode.com/todos", {
  method: "POST",
  body: JSON.stringify({
    userId: 1,
    title: "Fix my bugs",
    completed: false
  }),
  headers: {
    "Content-type": "application/json; charset=UTF-8"
  }
});

In the code above, the body holds the data to be sent to the server and added to the JSONPlaceholder todos API. Also, the headers hold the type of content you want to send to the server, which in this case is JSON data.

Note: It is always best to serialize your data before sending it to a web server or API using the JSON.stringify() method. This will help convert and ensure your JSON data is in string format.

The Fetch API is based on JavaScript promises, so you need to use the .then method to access the promise or response returned.

fetch("https://jsonplaceholder.typicode.com/todos", {
  method: "POST",
  body: JSON.stringify({
    userId: 1,
    title: "Fix my bugs",
    completed: false
  }),
  headers: {
    "Content-type": "application/json; charset=UTF-8"
  }
})
  .then((response) => response.json())
  .then((json) => console.log(json));

If this is successful, it will return the new JSON data you send to the server.

How to Send a POST Request with XMLHttpRequest

Like the Fetch API, XMLHttpRequest is also in-built and has existed much longer than the Fetch API. This means that almost all modern browsers have a built-in XMLHttpRequest object to request data from a server.

You will start by creating a new XMLHttpRequest object stored in a variable called xhr. This is important as it gives you access to all its objects using the variable.

For example, you can then open a connection with .open(), which is used to specify the request type and endpoint (the URL of the server). As you did for the FetchAPI, you will specify the type of data using the setRequestHeader method.

const xhr = new XMLHttpRequest();
xhr.open("POST", "https://jsonplaceholder.typicode.com/todos");
xhr.setRequestHeader("Content-Type", "application/json; charset=UTF-8")

The next step is to create the data to be sent to the server. Make sure you serialize the data and then store it in a variable that you'll send with the .send() method after making some checks with the .onload method.

const body = JSON.stringify({
  userId: 1,
  title: "Fix my bugs",
  completed: false
});
xhr.onload = () => {
  if (xhr.readyState == 4 && xhr.status == 201) {
    console.log(JSON.parse(xhr.responseText));
  } else {
    console.log(`Error: ${xhr.status}`);
  }
};
xhr.send(body);

When you put the code together, it will look like this and return the JSON data you send to the server:

const xhr = new XMLHttpRequest();
xhr.open("POST", "https://jsonplaceholder.typicode.com/todos");
xhr.setRequestHeader("Content-Type", "application/json; charset=UTF-8");
const body = JSON.stringify({
  userId: 1,
  title: "Fix my bugs",
  completed: false
});
xhr.onload = () => {
  if (xhr.readyState == 4 && xhr.status == 201) {
    console.log(JSON.parse(xhr.responseText));
  } else {
    console.log(`Error: ${xhr.status}`);
  }
};
xhr.send(body);

The major difference between the Fetch API and XMLHttpRequest method is that the Fetch API has a better syntax that is easier to read and understand.

At this point, you have learned how to use the two JavaScript inbuilt methods to send POST HTTP requests. Let’s now learn how to use Axios and jQuery.

How to Send a POST Request with Axios

Axios is an HTTP client library. This library is based on promises that simplify sending asynchronous HTTP requests to REST endpoints. We will send a GET request to the JSONPlaceholder Posts API endpoint.

Unlike the Fetch API and XMLHttpRequest, Axios is not built-in. This means you need to install Axios in your JavaScript project.

To install a dependency into your JavaScript project, you will first initialize a new npm project by running the following command in your terminal:

$ npm init -y

And now, you can install Axios in your project by running the following command:

$ npm install axios

Once Axios is successfully installed, you can send your POST request. This is quite similar to the Fetch API request.

You will pass the API endpoint/URL to the post() method, which will return a promise. You can then handle the promise with the .then() and .catch() methods.

axios.post("https://jsonplaceholder.typicode.com/todos", {
    userId: 1,
    title: "Fix my bugs",
    completed: false
  })
  .then((response) => console.log(response.data))
  .then((error) => console.log(error));

Note: Axios will automatically serialize the object to JSON and set the Content-Type header to 'application/json' for you.

This will return the new data sent to the server.

How to Send a POST Request with jQuery

Making an HTTP request in jQuery is similar to the Fetch API and Axios, but jQuery is not in-built. So you will first have to install or use its CDN in your project:

<script src="https://cdnjs.cloudflare.com/ajax/libs/jquery/3.6.2/jquery.min.js" integrity="sha512-tWHlutFnuG0C6nQRlpvrEhE4QpkG1nn2MOUMWmUeRePl4e3Aki0VB6W1v3oLjFtd0hVOtRQ9PHpSfN6u6/QXkQ==" crossorigin="anonymous" referrerpolicy="no-referrer"></script>

With jQuery, you can access the POST method $.post(), which takes in three parameters: the API endpoint/URL, the data to be sent to the server, and a callback function that runs when the request is successful.

const body = {
  userId: 1,
  title: "Fix my bugs",
  completed: false
};
$.post("https://jsonplaceholder.typicode.com/todos", body, (data, status) => {
  console.log(data);
});

Note: You can access the request's data and status in the callback function.

You can check this similar article on how to make an HTTP GET request in JavaScript.

Wrapping Up

In this article, you have learned how to send an HTTP POST request in JavaScript. You might now begin to think — which method should I use?

You can choose between the Fetch API and Axios if it's a new project. Also, if you want to consume basic APIs for a small project, Axios is optional because it demands installing a library.

Have fun coding!

You can access over 150 of my articles by visiting my website. You can also use the search field to see if I've written a specific article.

This interaction between your frontend application and the backend server is possible through HTTP requests.

There are five popular HTTP methods you can use to make requests and interact with your servers. One HTTP method is the GET method, which can retrieve data from your server.

This article will teach you how to request data from your servers by making a GET request. You will learn the popular methods that exist currently and some other alternative methods.

For this guide, we'll retrieve posts from the free JSON Placeholder posts API.

There are two popular methods you can easily use to make HTTP requests in JavaScript. These are the Fetch API and Axios.

How to Make a GET Request with the Fetch API

The Fetch API is a built-in JavaScript method for retrieving resources and interacting with your backend server or an API endpoint. Fetch API is built-in and does not require installation into your project.

Fetch API accepts one mandatory argument: the API endpoint/URL. This method also accepts an option argument, which is an optional object when making a GET request because it is the default request.

  fetch(url, {
      method: "GET" // default, so we can ignore
  })

Let’s create a GET request to get a post from the JSON Placeholder posts API.

fetch("https://jsonplaceholder.typicode.com/posts/1")
  .then((response) => response.json())
  .then((json) => console.log(json));

This will return a single post which you can now store in a variable and use within your project.

Note: For other methods, such as POST and DELETE, you need to attach the method to the options array.

How to Make a GET Request with Axios

Axios is an HTTP client library. This library is based on promises that simplify sending asynchronous HTTP requests to REST endpoints. We will send a GET request to the JSONPlaceholder Posts API endpoint.

Axios, unlike the Fetch API, is not built-in. This means you need to install Axios into your JavaScript project.

To install a dependency into your JavaScript project, you will first initialize a new npm project by running the following command in your terminal:

$ npm init -y

And now you can install Axios to your project by running the following command:

$ npm install axios

Once Axios is successfully installed, you can create your GET request. This is quite similar to the Fetch API request. You will pass the API endpoint/URL to the get() method, which will return a promise. You can then handle the promise with the .then() and .catch() methods.

axios.get("https://jsonplaceholder.typicode.com/posts/1")
.then((response) => console.log(response.data))
.catch((error) => console.log(error));

Note: The major difference is that, for Fetch API, you first convert the data to JSON, while Axios returns your data directly as JSON data.

At this point, you have learned how to make a GET HTTP request with Fetch API and Axios. But there are some other methods that still exist. Some of these methods are XMLHttpRequest and jQuery.

How to Make a GET Request with XMLHttpRequest

You can use the XMLHttpRequest object to interact with servers. This method can request data from a web server’s API endpoint/URL without doing a full page refresh.

Note: All modern browsers have a built-in XMLHttpRequest object to request data from a server.

Let’s perform the same request with the XMLHttpRequest by creating a new XMLHttpRequest object. You will then open a connection by specifying the request type and endpoint (the URL of the server), then you'll send the request, and finally listen to the server’s response.

const xhr = new XMLHttpRequest();
xhr.open("GET", "https://jsonplaceholder.typicode.com/posts/1");
xhr.send();
xhr.responseType = "json";
xhr.onload = () => {
  if (xhr.readyState == 4 && xhr.status == 200) {
    console.log(xhr.response);
  } else {
    console.log(`Error: ${xhr.status}`);
  }
};

In the above code, a new XMLHttpRequest object is created and stored in a variable called xhr. You can now access all its objects using the variable, such as the .open() method, when you specify the request type (GET) and the endpoint/URL where you want to request data.

Another method you will use is .send(), which sends the request to the server. You can also specify the format in which the data will be returned using the responseType method. At this point, the GET request is sent, and all you have to do is listen to its response using the onload event listener.

If the client's state is done (4), and the status code is successful (200), then the data will be logged to the console. Otherwise, an error message showing the error status will appear.

How to Make a GET Request with jQuery

Making HTTP requests in jQuery is relatively straightforward and similar to the Fetch API and Axios. To make a GET request, you will first install jQuery or make use of its CDN in your project:

<script src="https://cdnjs.cloudflare.com/ajax/libs/jquery/3.6.2/jquery.min.js" integrity="sha512-tWHlutFnuG0C6nQRlpvrEhE4QpkG1nn2MOUMWmUeRePl4e3Aki0VB6W1v3oLjFtd0hVOtRQ9PHpSfN6u6/QXkQ==" crossorigin="anonymous" referrerpolicy="no-referrer"></script>

With jQuery, you can access the GET method $.get(), which takes in two parameters, the API endpoint/URL and a callback function that runs when the request is successful.

$.get("https://jsonplaceholder.typicode.com/posts/1", (data, status) => {
  console.log(data);
});

Note: In the callback function, you have access to the request's data and the request's status.

You can also use the jQuery AJAX Method, which is quite different and can be used to make asynchronous requests:

$.ajax({
  url: "https://jsonplaceholder.typicode.com/posts/1",
  type: "GET",
  success: function (data) {
    console.log(data);
  }
});

Wrapping Up

In this article, you have learned how to make the HTTP GET request in JavaScript. You might now begin to think — which method should I use?

If it’s a new project, you can choose between the Fetch API and Axios. Also, if you want to consume basic APIs for a small project, there is no need to use Axios, which demands installing a library.

Have fun coding!

We interact with HTTP and HTTPS a lot in our day-to-day lives, but many people don't know the difference.

Most computer users just see that the browser is telling them their application is not safe and that a hacker might want to steal their important information. This leads to users running away faster than Usain Bolt's current record.

But this is avoidable. That is where HTTPS comes in and replaces HTTP. And we are going to discuss that today. :)

Here's What We'll Cover:

1. What is HTTP?
2. How HTTP works
3. Features of HTTP
4. How to know if a site is not secure
5. Are all HTTP websites insecure?
6. What is HTTPS?
7. How HTTPS works
8. Features of HTTPS
9. How encryption works
10. How to know if a site is secure
11. What is an SSL certificate?
12. How does SSL work?
13. How can I get SSL for my website?
14. Where can I get an SSL certificate?
15. Can I get an SSL certificate for free?
16. The main differences between HTTPS and HTTP
17. Conclusion

What is HTTP?

Hyper Text Transfer Protocol, or HTTP, is a communication method between your browser and the site you want to visit (web server).

This allows you to get the information that you need from the server on your browser.

A good way to understand HTTP and HTTPS is by using an analogy. We know that browsers and servers communicate using HTTP. HTTP is usually in plain text. Many people around the world speak English. If a hacker who knows English hacks into your computer, they can easily see any password you input.

Here in Kenya, in my mother tongue, we speak Turkana. If you don't speak the language and you come to Kenya and find two Turkanas speaking, you may not understand what they are saying.

That's the beauty of HTTPS. It is encrypted so that the hacker hopefully doesn't understand the communication between the browser and the server.


If I was to go to http://www.google.com, I would expect to see Google's default page.


The client, which in most cases is the web browser, sends a message which in computer terms is a request. Then the server will give back an answer, which is the response.

HTTP is very useful in sending HTML documents as well as images and videos to the web browser for the user to see. It is also used to send data to the server in HTML forms.


How HTTP Works

HTTP sends data through plain text. For example, if you were to access your bank's web page and they are using HTTP, a hacker may be able to access it and read any information that you send.

This is where HTTPS comes in. Many companies have implemented HTTPS to be able to allow their users to send data securely. We'll discuss this further below.

Features of HTTP

• Plain text. Initially when HTTP was developed, developers had one thing in mind: to serve only text documents. Now, HTTP is used in more ways than it was initially intended.

• Layer 7 protocol. HTTP is a layer 7 protocol in the OSI Model of networking. Layer 7 is the application layer. This layer is the top-most layer in the OSI model. The other layers include the physical, data link, network, transport, session, and presentation layer. To learn more about the OSI model, you can check out this free video on freeCodeCamp's YouTube channel by Brian Ferrill about how the internet works. There are more cookies in the jar other than the OSI model. Computer Networking Course - Network Engineering [CompTIA Network+ Exam Prep]

• Insecure. When you send HTTP requests they are sent through plain text. Also, when you get a response, you get it through plain text. This means that anyone who can access the requests and the responses can read them. 

• Light weight. The advantage of HTTP is that it is very lightweight. It is therefore very fast since it doesn't do the encryption stuff to secure the data, like HTTPS does.
• HTTP usually listens on port 80.

How to Know if a Site is Not Secure

When a site is not secure, Chrome will usually send a warning that says Your connection is not private. 

On Chrome, the URL bar will usually show Not Secure in red if a site is not secure. 

Are All HTTP Websites Insecure?

Well, let's look at an example. Imagine you are browsing a meme website, laughing at each one as you scroll by. If it is using HTTP, then you are off the hook. It's not a big deal.

You get bored and decide to go to your bank's site to access your account on your browser. If the site is not using HTTPS, you might as well be serving your account details to a hacker on a silver plate.

So the bottom line is, if you're browsing inconsequential information, HTTP is ok. But if you are dealing with insecure information, HTTP isn't enough.

What is HTTPS?

Hyper Text Transfer Protocol Secure, or HTTPS, is a way that communication can happen SECURELY between your browser and the site you want to visit (web server).

How HTTPS Works

HTTPS makes a secure connection by using a secure protocol that encrypts your data.

For most websites, the best way to have HTTPS is by getting an SSL (Secure Sockets Layer) Certificate or a TLS (Transport Layer Security) certificate.

At the moment, SSL has become advanced enough that it supports TLS. So you don't need to get a TLS certificate.

Features of HTTPS

• Encrypts data. Data encryption happens through the TLS/SSL protocol.
• It is a layer 4 (Transport layer) protocol.
• Key exchanges of public and private keys happen in HTTPS to encypt and decrypt data.
• Compared to HTTP, is it heavier. When encrpytion and decryption happens in HTTPS, it becomes heavier.
• HTTP listens on port 443.

  How Encryption Works


Let's say I type "I am a dev". This text gets encrypted when I click send, and then it gets decrypted on the server side.

The same is also true from the server side. If I get a response from the server, it will first get encrypted, then it will get decrypted on the client side.

How to Know if a Site is Secure

To know that a site is secure, you usually look at the URL bar where you can see a lock. If there is a lock, the connection from the client to the server is secure.


When you click on the lock icon, it tells you more about the secure connection.


What is an SSL Certificate?

An SSL certificate is a little file that tells browsers that your website –for example, freecodecamp.org – is who it says it is, and that it is reliable.

In order to authenticate, the certificate is able to confirm to the client (user) that the server they are connecting to is the one that manages that domain. All this is to keep the user safe from security issues such as domain spoofing.

It contains a public key and tells you who the owner of the website is that you are trying to connect to. If a website doesn't have an SSL certificate, it cannot be encrypted with TLS.

You can personally create your own SSL certificate (also known as a self-signed certificate), if you are the website owner. The problem with this approach is that browsers like Chrome don't trust these certificates. They prefer trusting certificates that are issued by a certificate authority.

How Does SSL Encryption Work?

There are two types of SSL encryption, asymmetric and symmetric. The combination of asymmetric and symmetric is what makes SSL Encryption work. Let's look at them below to learn more.

What is asymmetric encryption?

In Asymmetric encryption, you have two keys. These are:

1. Public key.
2. Private key.


The client/user/browser gives the public key to the server with which they are communicating. Then, the encyption happens with the help of the public key, and the decryption happens with the help of the server's private key.

The private key can only be found on that particular server. No one else has it. This shows you why asymmetric encryption is stronger and tougher to hack, because it has two different keys, the private and public key. The two keys work together to make sure the data is more secure.

This also tells you why the size of this encryption is 1024/2048 bits.

What is symmetric encryption?

In symmetric encryption, it's very simple. You have one key, and that's it. The client uses one key for encryption, and the server uses the same key for decrypting the data.

Symmetric encryption is very light weight. The size is 128/256 bits. But it is a bit easier to hack into as compared to asymmetric. This doesn't mean it is not useful. When we use SSL, we combine Asymmetric and Symmetric to be able to make the communication safer and more secure.


How asymmetric + symmetric encryption work

The combination of both asymmetric and symmetric is now the double-sided wall. 

In the first step, the server will send to the browser the asymmetric public key. As we now know, the asymmetric key has both the public key and the private key. Therefore, the browser will receive the public key.

After this, the browser generates a session key.

Symmetric encryption uses only one single key for both the client and the server. So what will happen is, the browser will generate a local session key. This is a symmetric encryption session key. It will then encrypt it, with the use of the public key which is asymmetric, given in the first step. The locally generated session key will then be combined with the public key, and sent to the server.

The server will then use a private key to decrypt the encrypted session key it has received. In this particular step, the server will use asymmetric private key to decrypt the session key it has received.

Now, once the decryption has happened, the server and the browser will use the session key for communication. The session key will only be used for that specific session.

Let's say you close your browser, and maybe sign in the next day – everything starts all over again. Session keys get created again.

How Can I Get SSL for My Website?

If you are a website owner, you can acquire an SSL certificate from a certificate issuing authority.

You will then need to install the certificate on you web server where your website is hosted. Most of the time, the hosting company where you host your website handles this process for you.

Where Can I Get an SSL Certificate?

There are organizations that issue security certificates. These organizations are called certificate authorities. Some of these certificate authorities include: DigiCert, Comodo, and many others.

Many developers get certificates from these organizations. Since they are the most widely used certificate issuers, browsers usually trust certificates from these organizations.

Can I Get an SSL Certificate for Free?

Cloudflare offers SSL certificates for free. It is one of the first internet security companies to do so.

If you want to get one, you can check it out here.

What is HTTPS Used For?

HTTPS helps a lot with security. Without it, passing sensitive information becomes a big challenge especially if your business requires a secure way of communication.

Sites that accept online payments like ecommerce sites typically require HTTPS. This is to avoid information such as credit card details and login information from being stolen (Source: Tony Messer).

The Main Differences between HTTPS and HTTP

• The encryption layer is enabled in HTTPS while there is no encryption layer in HTTP.
• Your data is protected in HTTPS while in HTTP it is not.
• Your ranking is boosted in Google when you use HTTPS while with HTTP, you don't get any ranking boost.
• You are protected against phishing when you use HTTPS while there is not protection when using HTTP.
• You are compliant with the regulations of the payment industry when you use HTTPS while HTTP is non-compliant.
• Loading HTTPS in the first few seconds may be slower than loading HTTP.
• Getting SSL certificates can cost money while there is no certification costs with HTTP.
• While using HTTPS, you become buddies with Google Chrome. Google Chrome doesn't like HTTP and therefore you will always be getting unsecured site notifications.

Conclusion

HTTP and HTTPS are very important in our day to day lives as developers. The communication between the browser and the server is what fuels much the work we do.

By protecting your users' data as much as you're able so their information doesn't get stolen, you'll gain their trust and provide a better user experience.

See you soon.

For a developer, this error can be hard to resolve because, on many occasions, it doesn’t show what you need to do to fix it.

But if you’re surfing the net as a user and you encounter the error, there could be a hint showing what to do.

In this case, you should wait a bit to make another request. For security reasons, the period of time to wait might not be specified. But if the website proritzes user experience, they'll show you how much time to wait before making another request.

In this article, I will explain what the 429 error means and how a developer might have implemented it. I will also show what you can do to resolve it as an internet user.

What is the 429 Error?

The 429 error is an HTTP status code. It tells you when the use of an internet resource has surpassed the number of requests it can send within a given period of time.

This error might be shown to you in another form like:

• Error 429
• 429 Too many requests
• 429 (Too many requests)

It all depends on how the administrator in charge of the internet resource customizes it.

In the small app I built to show you how rate limiting is implemented in an Express app, this is how I customized the error:

With this error, the administrators in charge of a website or internet resource are telling you they don’t have enough resources to handle the number of requests you are sending over. This is called “rate limiting”.

What Causes the 429 Error?

The most common cause of the 429 error is not having enough resources to handle so many concurrent requests.

For example, if this error is shown on a hosting server, it could mean that the package you’re using has a limit for the number of requests you can send.

And if the error comes up while making an API request, it means you’ve exceeded the number of requests you can make for a certain period of time.

Also, if a user tries to access a page on a website too often, the server of that website could trigger a rate-limiting feature implemented in it. So, this is a good security measure to put in place in order to prevent attacks from hackers.

For example, this is how you can implement rate limiting in an Express app using the express-rate-limit package:

// Import deps
const express = require("express");
const rateLimit = require("express-rate-limit");

const app = express();

// Port
const port = 4000;

const limiter = rateLimit({
  windowMs: 5 * 60 * 1000,
  max: 5, // Limits each IP to 5 per 15 minutes
  message:
    `<h1 style='display:flex; align-items:center; justify-content:center; height:100vh'>
     429 - Too many Requests <br> Try again later!
    </h1>`,
});

// Apply to all requests
app.use(limiter);

app.get("/", limiter, (req, res) => res.send("Hello World!"));

app.listen(port, () => console.log(`App listening on port ${port}!`));

And when the limit is surpassed for the number of seconds specified, this message gets shown to the user:

What you can do to Resolve the 429 Error

As an internet user, you should wait a bit before making another request. But if the error persists, you should contact the website administrator.

If you’re a web administrator, you should reduce the number of requests you make within the specified time (if any). If you are in control of the limit yourself, you should increase it for a particular period of time.

If the website you’re handling is a WordPress website, one of your plugins or themes might be causing the 429 error. You should disable your site plugins and themes one by one to see which one of them is the cause.

If the error is related to hosting, you should contact the customer care service of your hosting provider.

Conclusion

No website admin wants their server to get clunked up or crash. So, from a technical perspective, the 429 error is not an error. It’s the server’s way of telling you it doesn’t have enough resources to handle the high number of requests you’re making.

Thank you for reading.

On many occasions, this error is an issue with the website itself, so on your end, there’s nothing you can do to solve it.

But the error can also occur if your network adapters or network settings of your computer are badly configured.

The “502” in the error is an HTTP status code that indicates one server received an invalid response from another server.

Google shows the error this way:

Sometimes, a popular forum in my country shows it this way:

It looks like websites powered by Cloudflare show the error that way.

Some other websites show it in their own customized way.

What Exactly Does 502 Bad Gateway Mean?

The international engineering task force (IETF) defines the 502 Bad Gateway Error in a more extensive way:

The 502 (Bad Gateway) status code indicates that the server while acting as a gateway or proxy, received an invalid response from an inbound server it accessed while attempting to fulfill the request.

The “proxy server” is a system or router that acts as a gateway between your computer and the internet.

The inbound server, on the other hand, is the one conveying an incoming connection onto your computer. That is, a web server.

What Causes a Bad Gateway Error?

As earlier pointed out, 502 Bad Gateway is a server error just like other HTTP status code errors in the 500 range such as 501 (Not Implemented), 503 (Service Unavailable), 504 (Gateway Timeout), and 505 (HTTP Version not supported).

This particular server error could be an overloaded server, programming, and backend configuration error, or even a yet-to-be-propagated domain name.

But sometimes, the browser could throw this error due to past-due updates, ad-blockers, browser extensions, or computer DNS server problems.

Final Thoughts

I hope this article helps you understand what the 502 Bad Gateway error means.

If you’re a web administrator and your users are complaining of this error, you should try to fix it as soon as possible as it could have a negative effect on your website's SEO.

If you’re facing this error as a user, there’s a high chance it’s from the website you’re trying to visit. Some other times, it could be due to a badly configured router and settings.

You can try refreshing the web page, clearing your browser cache, and switching to another browser.

To see how you can solve the error as a user, I wrote a detailed article that can help you out.

Thank you for reading.

HTTP status codes allows us know if our request to the server was successful or not. Here are the status codes and what each type means:

• 100 - 199 (Informational).
• 200 - 299 (Successful).
• 300 - 399 (Redirection).
• 400 - 499 (Client error).
• 500 - 599 (Server error).

In this article, we'll be talking about the 504 error which falls under the server error category. We'll see some of the reasons why you might encounter this error and the possible ways of fixing it.

What Is the HTTP 504 Error?

From the status codes listed before this section, we can see that the 504 error is a server error. This means that it is not a problem from our end as the client. Our request was sent successfully to the server but something went wrong while we were awaiting a response.

You'll usually get a response saying "Gateway Timeout Error" or something similar if it is a 504 error.

This error occurs when our server doesn't receive a response fast enough from the server where our request was sent. As a result of the delay, our server times out and returns an error instead.

The reasons for this error can vary. The server where the request was sent to could be down for maintenance or overloaded, amongst other reasons.

How to Fix the HTTP 504 Error

In this section, we'll talk about some of the ways in which you can fix the 504 error.

The following solutions are for users visiting websites:

Refresh Your Browser

The first thing you should try when you encounter this error is to refresh your browser. Each browser usually has a shortcut for refreshing, but you can always use the refresh button.

Disconnect and Reconnect Your Network Devices

If refreshing your browser doesn't fix the problem then you should try disconnecting from and reconnecting to your network devices. This could be a modem, a router, a Wi-Fi hotspot, and so on.

Clear Browser Data and Cookies

Each browser has a way of clearing data and cookies but this is usually in the browser settings.

While this may fix the problem, you should know that in most cases, it doesn't – so be sure you are willing to get rid of the data and cookies before proceeding.

Find Out If Other Users Are Experiencing the Same Problem

If you are on any community platform or know other users who make use of the website then you should probably try and find out from them to see if it is a general problem.

If this is a general problem then you can sit back and relax. The website owners might be up to something on the backend.

Note that trying these fixes above may not work all the time. In situations like this, the best thing to do is to wait and try later because it is usually not a problem from your end as the client.

The following solutions are for you if you own a website:

Contact Your Hosting Provider

In cases where the website belongs to you and users cannot access it, you should try contacting your hosting provider to be sure everything is in check.

It could be as a result of your hosting plan requiring an upgrade because you may have reached the limits of your current plan.

Check for DNS Changes

When you change servers for your website, the DNS information changes will usually take some time before updating. So you can inform your users of changes like this before or after they happen.

DNS stands for Domain Name System. They change domain names to IP addresses which browsers can easily recognize before loading websites.

Conclusion

In this article, we talked about the HTTP 504 error. We talked about HTTP status codes and found out what category the 504 error belonged to.

We then talked about why this error might happen and some of the possible ways of fixing it.

Thank you for reading!

Before we get into REST, let's learn what an API is. I believe this will help you understand REST better.

What is an API?

Since we're talking about REST APIs, our definition of an API will not go beyond the scope of the web.

API stands for Application Programming Interface. An API establishes a connection between programs so they can transfer data.

A program that has an API implies that some parts of its data is exposed for the client to use. The client could be the frontend of the same program or an external program.

In order to get this data, a structured request has to be sent to the API. If the request meets the desired requirements, a response which contains the data gets sent back to where the request was made. This response usually comes in the form of JSON or XML data.

In some cases, you'll need some sort of authorization to gain access to external API data.

Every API has documentation that tells you what data is available and how to structure your request in order to get a valid response.

API Example

Was that confusing?

Let's use a real life scenario to give an example.

Imagine visiting a new restaurant. You're there to order food, and since you haven't been there before, you don't exactly know what type of food they serve.

The server then approaches you with a menu so you can pick what you'd like to eat. After making your choice, the server then goes to the kitchen and gets your food.

In this case, the server is the API who is connecting you to the kitchen. The API's documentation is the menu. The request is made when you pick what you'd like to eat, and the response is the food being served.

I hope that helps you understand what an API is and how it works.

What is REST?

REST stands for REpresentational State Transfer. It is a standard that guides the design and development of processes which enable us interact with data stored on a web servers.

The above definition may not look as complex or "professional" as the ones you come across on the internet, but the goal here is for you to understand the basic purpose of REST APIs.

An API that complies with some or all of the six guiding constraints of REST is considered to be RESTful.

We are able to communicate with servers using the HTTP protocol. With these protocols, we can Create, Read, Update and Delete data – otherwise known as CRUD operations.

But how can we perform these CRUD operations and communicate with data on the server?

We can do this by sending HTTP requests, and that is where REST comes in. REST simplifies the communication process by providing various HTTP methods/operations/verbs which we can use to send requests to the server.

How to communicate with a server using REST APIs

As we discussed in the last section, REST APIs make the communication process with the server easier for us by giving us various HTTP request methods. The most commonly used methods are:

• GET: The get method is used to Read data on the server.
• POST: The post method is used to Create data.
• PATCH/PUT: The patch method is used to Update data.
• DELETE: The delete method is used to Delete data.

These methods provided by REST allow us perform CRUD operations easily. That is:

Create => POST.
Read => GET.
Update => PATCH/PUT.
Delete => DELETE.

So if we are to make a request to a server, let's say to retrieve data, we are going to make a GET request to an endpoint/resource provided by the server. The endpoint is similar to a URL.

If the request made is a valid one, then the server will respond to us with the data we requested. It also sends a status code where 200 is a success and 400 is a client error.

Here is an example of a request made to the JSONPlaceholder API using JavaScript:

fetch('https://jsonplaceholder.typicode.com/todos/1')
  .then(response => response.json())
  .then(json => console.log(json))

When making a request using the fetch API, the default method is the GET method – so we are not forced to specify it. But we do need to specify when making a request using the other methods.

In the code example above, the endpoint is https://jsonplaceholder.typicode.com and the specific data we are requesting is one todo item. The data will be returned to us in JSON format.

If we were to make a POST request, then we would include the method type which would be POST and a request body which would contain the data we are creating to send to the server.

Deleting would require that we use the corresponding request method along with the id of the todo item we want to delete. Like this:

fetch('https://jsonplaceholder.typicode.com/posts/3', {
  method: 'DELETE',
});

Updating would require both the id and the request body that would be used to update the data. Here is an example:

fetch('https://jsonplaceholder.typicode.com/posts/5', {
  method: 'PATCH',
  body: JSON.stringify({
    title: 'new todo',
  }),
  headers: {
    'Content-type': 'application/json; charset=UTF-8',
  },
})
  .then((response) => response.json())
  .then((json) => console.log(json));

Conclusion

In this tutorial, you learned what REST is and how it helps us communicate with the server efficiently.

We defined an API and gave an example to help explain its meaning. We also got to know some of the methods provided by REST to create, read, update and delete data stored on the server.

Thank you for reading!

In this article, we'll be discussing the get, put, and post HTTP methods. You'll learn what each HTTP method is used for as well as why we use them.

In order to get a deep understanding of how HTTP methods work, I'll also go over key context and background information.

Topics we'll cover in this post:

• HTTP Protocol
• Client-server architecture
• APIs

By the end of this article you'll have a good understanding of the functions of each request method. You'll also have experience making requests and working with a web API.

What is HTTP?

HTTP is a protocol, or a definite set of rules, for accessing resources on the web. Resources could mean anything from HTML files to data from a database, photos, text, and so on.

These resources are made available to us via an API and we make requests to these APIs via the HTTP protocol. API stands for application programming interface. It is the mechanism that allows developers to request resources.

Client-Server Architecture

In order to understand the HTTP methods, it’s important to cover the concept of client/server architecture. This architecture describes how all web applications work and defines the rules for how they communicate.

A client application is the one that a user is actually interacting with, that's displaying the content. A server application is the one that sends the content, or resource, to your client application. A server application is a program that is running somewhere, listening, and waiting for a request.

The main reason for this separation is to secure sensitive information. Your entire client application gets downloaded into the browser, and all of the data can be accessed by anyone accessing your web page.

This architecture helps protect things like your API keys, personal data, and more. Now modern tools like Next.js and Netlify allow developers to run server code in the same app as their client app, without needing a dedicated server application.

Client-Server Communication

Client and server applications communicate by sending individual messages on an as-needed basis, rather than an ongoing stream of communication.

These communications are almost always initiated by clients in the form of requests. These requests are fulfilled by the server application which sends back a response containing the resource you requested, among other things.

Why We Need A Server-Client Architecture

Let’s say you were building a weather web app, for example. The weather app that your user is going to interact with is the client application – it has buttons, a search bar, and displays data like city name, current temperature, AQI, and so on.

This weather app wouldn’t have every city and its weather information coded directly into it. This would make the app bloated and slow, would take forever to research and manually add to a database, and would be a headache to update every single day.

Instead, the app can access weather data by city using the Weather web API. Your app would gather your user’s location and then make a request to the server saying, “Hey, send me the weather information for this specific city.”

Depending on what you are trying to achieve, you would use the various request methods that are available. The server sends back a response containing the weather information and a few other things, depending on how the API is written. It may also send back things like a timestamp, the region this city is located in, and more.

Your client application communicated with a server application running somewhere, whose only job is to listen continuously for a request to that address. When it receives a request, it works to fulfill that request either by reading from a database, another API, local file, or a programmatic calculation based on data you pass in.

The Anatomy of an HTTP Request

An HTTP request must have the following:

• An HTTP method (like GET)
• A host URL (like https://api.spotify.com/)
• An endpoint path(like v1/artists/{id}/related-artists)

A request can also optionally have:

• Body
• Headers
• Query strings
• HTTP version

The Anatomy of an HTTP Response

A response must have the following:

• Protocol version (like HTTP/1.1)
• Status code (like 200)
• Status text (OK)
• Headers

A response may also optionally have:

• Body

HTTP Methods Explained

Now that we know what HTTP is and why it’s used, let’s talk about the different methods we have available to us.

In the weather app example above, we wanted to retrieve weather information about a city. But what if we wanted to submit weather information for a city?

In real life, you probably wouldn’t have permissions to alter someone else’s data, but let’s imagine that we are contributors to a community-run weather app. And in addition to getting the weather information from an API, members in that city could update this information to display more accurate data.

Or what if we wanted to add a new city altogether that, for some reason, doesn’t already exist in our database of cities? These are all different functions – retrieve data, update data, create new data – and there are HTTP methods for all of these.

HTTP POST request

We use POST to create a new resource. A POST request requires a body in which you define the data of the entity to be created.

A successful POST request would be a 200 response code. In our weather app, we could use a POST method to add weather data about a new city.

HTTP GET request

We use GET to read or retrieve a resource. A successful GET returns a response containing the information you requested.

In our weather app, we could use a GET to retrieve the current weather for a specific city.

HTTP PUT request

We use PUT to modify a resource. PUT updates the entire resource with data that is passed in the body payload. If there is no resource that matches the request, it will create a new resource.

In our weather app, we could use PUT to update all weather data about a specific city.

HTTP PATCH request

We use PATCH to modify a part of a resource. With PATCH, you only need to pass in the data that you want to update.

In our weather app, we could use PATCH to update the rainfall for a specified day in a specified city.

HTTP DELETE request

We use DELETE to delete a resource. In our weather app, we could use DELETE to delete a city we no longer wanted to track for some reason.

HTTP Method FAQs

What’s the difference between PUT and POST?

PUT requests are idempotent, meaning that executing the same PUT request will always produce the same result.

On the other hand, a POST will produce different outcomes. If you execute a POST request multiple times, you'll create a new resource multiple times despite them having the same data being passed in.

Using a restaurant analogy, POSTing multiple times would create multiple separate orders, whereas multiple PUT requests will update the same existing order.

What’s the difference between PUT and PATCH?

The key differences are that PUT will create a new resource if it cannot find the specified resource. And with PUT you need to pass in data to update the entire resource, even if you only want to modify one field.

With PATCH, you can update part of a resource by simply passing in the data of the field to be updated.

What if I just want to update part of my resource? Can I still use PUT?

If you just want to update part of your resource, you still need to send in data for the entire resource when you make a PUT request. The better-suited option here would be PATCH.

Why is a body optional for a request and response?

A body is optional because for some requests, like resource retrievals using the GET method, there is nothing to specify in the body of your request. You are requesting all data from the specified endpoint.

Similarly, a body is optional for some responses when a status code is sufficient or there is nothing to specify in the body, for example with a DELETE operation.

HTTP Request Examples

Now that we’ve covered what an HTTP request is, and why we use them, let’s make some requests! We’re going to be playing with the GitHub Gist API.

"Gist is a simple way to share snippets and pastes with others. All Gists are Git repositories, so they are automatically versioned, forkable and usable from Git." (Source: Github)

You will need a GitHub account for this. If you don’t already have one, this is a great opportunity to start one to save your code in the future.

Every user on GitHub can create gists, retrieve their gists, retrieve all public gists, delete a gist, and update a gist, amongst other things. To keep things simple we will use Hoppscotch, a platform with a nice interface used to quickly and easily make HTTP requests.

A quick Hoppscotch walkthrough:

• There is a drop down menu where you can select the method you want to create a request with.
• There is a text box where you should paste the URL of of the API endpoint you want to access.

• There is a Headers section where we will be passing in headers as instructed by the GitHub docs.

• There is a body area where we will pass in content to our body as instructed by the GitHub docs.

• The right column will quickly let you know if your request was successful. If it is green, you successfully made your request, and if it's red there was an error.

How to Make a GET Request

To make a GET request to retrieve all of a specific users’ gists, we can use the following method and endpoint: GET /users/{username}/gists. The documentation tells us the parameters that we can pass in to make this request.

We see that in the path we have to pass in a string with the target user’s username. We also see that we have to pass in a header called accept and set it to application/vnd.github.v3+json.

We're given the URL for this API:

https://api.github.com

We're given the endpoint path for this specific operation:

/users/{username}/gists

To make this request:

1. Paste in the full URL + path in the input field of Hoppscotch. Be sure to replace username with an actual username. If you don't have a GitHub with existing Gists, you can use mine: camiinthisthang.
2. Select the GET request method
3. In the Headers tab, set accept as a header and set the value to application/vnd.github.v3+json

4. Hit send!

At the bottom, you'll see your response formatted as JSON. In order to read this more clearly, copy the response and paste it into an online JSON formatter.

In the formatter, you're able to tell that the response is an array of objects. Each object represents one gist, showing us information like the URL, the ID, etc.

How to Make a POST Request

Now let's create a resource using the POST method. In this context, the new resource would be a new gist.

First we’ll have to create a personal access token. To do that, go to your settings page and hit Generate token.

Name your token and select the scope “Create Gists”:

Then click the green Generate token button at the bottom of the page.

Copy your access code and paste it somewhere you can easily retrieve it.

Now we're ready to make our request! The documentation tells us we should pass in a header, and a files object in the body. We can optionally pass in a few other things, including a boolean that dictates if this gist is public or private.

We're given the URL for this API:

https://api.github.com

We're given the endpoint path for this specific operation:

/gists

To make this request:

1. Paste the full URL + path into the input field of Hoppscotch.
2. Select the POST request method
3. In the Headers tab, set accept as a header and set the value to application/vnd.github.v3+json
4. In the Body tab, set the content type to application/json. Then start off with an object {}.

Inside of this object, we'll set the public boolean to true. Then we'll define the property files, and the value is another object with a key of the name of your new gist. The value for this should be another object whose key is content. The value here should be whatever you want to actually add to the gist.

Here is the code for you to copy/paste:

{
  "public": true, 
  "files": {
    "postgist.txt": {
      "content": "Adding a GIST via the API!!"
    }
  }
}

5. In the Authorization tab, set the authorization type to Basic Auth. Type in your Github username and pass your personal access token we created in the password field.

After we run this, we get a long response. An easy way to check that your gist was created is to go to your Gists in GitHub.

We see that we successfully added a Gist!

How to Make a PATCH Request

Let's update the title and description of the Gist we just created. Remember: PATCH allows you to update a part of a resource, not the entire resource. Anything that we don’t pass in will remain unchanged.

We didn’t actually pass a description to our Gist when we created it, so we can patch this and create one.

We're given the URL for this API:

https://api.github.com

We're given the endpoint path for this specific operation:

/gists/{gist_id}

To make this request:

1. Paste in the full URL + path in the input field of Hoppscotch. Get the Gist ID of the gist you want to update. You can find the ID by going to the Gist in GitHub and copying the alphanumeric string at the end of the URL.

2. Select the PATCH request method.

3. In the Headers tab, set accept as a header and set the value to application/vnd.github.v3+json.

4. In the Authorization tab, set the authorization type to Basic Auth. Type in your GitHub username and pass your personal access token we created in the password field.

5. In the Body tab, we'll pass in the updated description and title. Here is the code:

{
  "description": "Adding a description via the API", 
  "files": {
    "postgist.txt": {
      "content": "Adding a GIST via the API!! -- adding this line at the end to make the content slightly longer"
    }
  }
}

If we refresh our Gist, we see that we have an updated title and description!

How to Make a DELTE Request

Let's delete the Gist we created. We should pass in the header and the Gist ID.

We're given the URL for this API:

https://api.github.com

We're given the endpoint path for this specific operation:

/gists/{gist_id}

To make this request:

1. Paste in the full URL + path in the input field of Hoppscotch. Get the Gist ID of the gist you want to update. You can find the ID by going to the Gist in GitHub and copying the alphanumeric string at the end of the URL.

2. Select the DELETE request method

3. In the Headers tab, set accept as a header and set the value to application/vnd.github.v3+json.

If we navigate to our Gists, we see that this one doesn't exist and we successfully deleted the resource.

How to Make Requests in Your App

We used Hoppscotch because it lets us quickly make requests without having to spin up a whole app or download anything.

If you wanted to make requests in a JavaScript/React app, you could use Javascript fetch or Axios.

For a step-by-step code walk through of how to make a simple app that uses HTTP request methods and an API, check out my video on youtube where we create a web app that displays information about all of the countries via an API.

You Did It!

If you're reading this, go ahead and give yourself a pat on the back because you've learned about web APIs, the HTTP protocol, the client-server architecture – and you've also made your first requests.

If you liked this style of teaching, I create content specifically for beginners and early-career engineers on YouTube, Tik Tok, Twitter, and Hashnode. You can also find code snippets and a way to reach me via my personal website.