HTTP Requests in Firebase Functions: Fundamentals Quiz Quiz

Assess your understanding of handling HTTP requests using Firebase Functions. This quiz covers key concepts such as request and response objects, routing, request parsing, security practices, and typical use cases in serverless environments.

1. Understanding HTTP Triggers

   Which type of function is primarily used to handle incoming HTTP requests in Firebase Functions?

   1. HTTP Triggered Function
   2. Event Triggered Function
   3. Cron Triggered Function
   4. Database Triggered Function

   Explanation: An HTTP Triggered Function is designed to respond directly to HTTP requests, making it suitable for serverless APIs and webhooks. Cron and Database Triggered Functions respond to scheduled or database events, not HTTP requests. Event Triggered Functions typically handle background events rather than direct user requests over HTTP.

2. Handling Request Objects

   When an HTTP request is received by a Firebase Function, which parameter contains details about the incoming request such as headers and body?

   1. request
   2. event
   3. context
   4. response

   Explanation: The 'request' parameter holds information about the incoming HTTP request, including data such as headers, body, and query parameters. The 'response' is used to send data back to the client. 'Context' and 'event' are more commonly associated with background function triggers or other environments, not with direct HTTP request handling.

3. Sending Responses

   Which method on the response object should you use to send a JSON response to the client?

   1. response.sendText()
   2. request.writeJSON()
   3. request.sendJSON()
   4. response.json()

   Explanation: The correct way to send a JSON response is to use response.json(), which formats the output as JSON before sending it to the client. Methods like response.sendText() or request.writeJSON() do not exist, and request.sendJSON() is also incorrect since the response object, not the request, handles outgoing data.

4. Routing Requests

   In Firebase Functions, what technique can you use to handle different URL paths for a single HTTP-triggered function?

   1. Check request.path or request.url
   2. Set up multiple HTTP functions for each path
   3. Only use Firebase Database triggers
   4. Import external routing files automatically

   Explanation: By checking request.path or request.url, you can route requests within a single HTTP function to different logic based on their URL. Setting up multiple HTTP functions is less efficient, while using database triggers is unrelated. Importing routing files automatically is not a built-in feature; custom logic is needed for routing.

5. Parsing JSON Data

   How do you safely access JSON data sent in the body of an HTTP POST request to a Firebase Function?

   1. Read request.query for data
   2. Parse headers directly
   3. Access request.params universally
   4. Use request.body when headers indicate JSON

   Explanation: When the request's Content-Type header is set to application/json, the request.body property will already contain the parsed JSON data. Parsing headers directly won't yield data, request.query only contains URL parameters, and request.params is not always available or appropriate for request bodies.

6. Default HTTP Methods

   Which HTTP methods are available for handling in an HTTP-triggered Firebase Function?

   1. Only GET and POST
   2. Only POST
   3. All methods like GET, POST, PUT, DELETE, etc.
   4. Only PATCH and DELETE

   Explanation: HTTP-triggered functions can handle all standard methods such as GET, POST, PUT, PATCH, DELETE, and more by checking request.method. Limiting to only GET, POST, or specific methods is unnecessary unless you choose to restrict them yourself within the code.

7. Securing Endpoints

   What is a common way to restrict access to a sensitive HTTP endpoint implemented with a Firebase Function?

   1. Store secrets in the request body
   2. Print logs to the console
   3. Skip setting response status
   4. Check authorization tokens in request headers

   Explanation: Validating authorization tokens in request headers is a standard security practice for controlling access to HTTP endpoints. Skipping the response status, storing secrets in request bodies, or only logging do not provide access control or safeguard sensitive endpoints.

8. Using Query Parameters

   If a client sends a GET request with ?userId=123, how should you access the value '123' inside the function?

   1. request.body.userId
   2. request.query.userId
   3. response.query.userId
   4. headers.userId

   Explanation: The query parameter userId can be accessed via request.query.userId, which reads parameters in the URL after the question mark. response.query.userId is not a valid property, request.body.userId refers to POST data, and headers.userId would require a custom header, not a query parameter.

9. Handling CORS

   Why might you need to set CORS headers when building an HTTP API with Firebase Functions for web clients?

   1. To force HTTP methods to uppercase
   2. To parse cookies in the request body
   3. To increase request speed
   4. To allow browser-based clients on different origins to access your function

   Explanation: Setting CORS headers is needed so browsers permit web clients on different origins to interact with your HTTP API. This has nothing to do with HTTP method casing, request speed, or cookie parsing. Failing to set CORS headers can prevent browsers from accessing your API due to security restrictions.

10. Returning Status Codes

    What HTTP status code should you send in the response to indicate a successful request in your Firebase Function?

    1. 500
    2. 404
    3. 200
    4. 301

    Explanation: A 200 status code indicates a successful HTTP request. 301 denotes a permanent redirect, 404 means resource not found, and 500 signals a server error. Using the correct status code helps clients understand the result of their request.