Web APIs with .NET: REST, gRPC, and GraphQL Essentials Quiz Quiz

Explore key concepts of building Web APIs in .NET using REST, gRPC, and GraphQL. This quiz covers API design, protocol choices, serialization, endpoints, and security to help reinforce your foundational knowledge of modern Web API approaches.

  1. Understanding REST API Basics

    Which HTTP verb is typically used in RESTful APIs to retrieve data about a specific resource, such as retrieving a user's details by their ID?

    1. POST
    2. GET
    3. REMOVE
    4. PATCH

    Explanation: GET is the standard HTTP method for retrieving data or resources without modifying them. POST is used to create new resources, PATCH is intended for partial updates, and REMOVE is not a standard HTTP verb. Therefore, GET is the most suitable and widely recognized choice for data retrieval.

  2. gRPC Protocol Features

    Which serialization format does gRPC primarily use for efficient communication between services?

    1. XML
    2. Protocol Buffers
    3. JSON
    4. YAML

    Explanation: Protocol Buffers is a compact, high-performance binary serialization format designed for gRPC, enabling fast communication. JSON and XML are commonly used with REST APIs, while YAML is a human-readable format often used in configuration files. Only Protocol Buffers is natively integrated into the core of gRPC.

  3. GraphQL Query Structure

    In a GraphQL API, how does the client specify exactly which fields of a resource it wants to retrieve, such as requesting only the 'name' of a product?

    1. By defining fields in the query body
    2. Using a request verb like SELECT
    3. By adding a custom HTTP header
    4. Through URL query strings

    Explanation: In GraphQL, clients customize their responses by specifying required fields directly within the query body. Custom HTTP headers and URL query strings are typical to REST, not GraphQL, and there is no SELECT verb in HTTP. Thus, providing fields in the query body is unique to GraphQL's flexibility.

  4. Resource Identification in REST

    What is the main purpose of a Uniform Resource Identifier (URI) in a REST API, for example, /api/books/23?

    1. To uniquely identify a resource
    2. To specify the request format
    3. To authenticate a user
    4. To define the response schema

    Explanation: A URI is designed to uniquely identify and locate a resource in REST APIs. The request format and response schema are unrelated to the URI, while authentication is generally managed by headers or tokens. This makes the resource identification function the correct answer.

  5. Choosing Between REST and gRPC

    When should you consider using gRPC instead of REST for your .NET API, given you have multiple microservices communicating within the same data center?

    1. When human-readable data transmission is mandatory
    2. When accessing APIs directly from a browser with basic tools
    3. When only JSON-based clients are supported
    4. When low latency and efficient binary communication are required

    Explanation: gRPC shines in scenarios demanding performance, low latency, and binary protocols, such as microservices in a data center. REST is better for human-readable communication and browser compatibility. REST also fits when JSON is required exclusively. Thus, using gRPC for efficiency is the right context.

  6. GraphQL API Operations

    Which GraphQL operation should you use to modify or add data, such as creating a new order in an e-commerce system?

    1. Query
    2. Action
    3. Mutation
    4. Subscription

    Explanation: A Mutation operation in GraphQL handles creating or modifying data. Queries are for retrieving data, Subscriptions are for real-time updates, and 'Action' is not an official GraphQL term. Using Mutations for data changes is the core approach in GraphQL APIs.

  7. RESTful Status Codes

    Which HTTP status code should a REST API return when a resource is successfully created, such as after registering a new account?

    1. 400 Bad Request
    2. 404 Not Found
    3. 201 Created
    4. 200 OK

    Explanation: 201 Created is the standard code for successful resource creation. 200 OK is used for successful general requests but does not indicate creation. 400 and 404 represent client errors, not success. Therefore, 201 Created is the correct status for new resources.

  8. gRPC Communication Patterns

    Which gRPC communication pattern allows both the client and server to send multiple messages as part of a single call, for example, streaming live updates between services?

    1. Unary
    2. Client streaming
    3. JSON polling
    4. Bidirectional streaming

    Explanation: Bidirectional streaming allows messages to flow in both directions throughout the lifetime of a gRPC call. Unary is single request-response, and client streaming is one-way from client to server only. 'JSON polling' is not a gRPC communication pattern. Bidirectional streaming is designed for continuous, two-way communication.

  9. Authentication in APIs

    Which technique is commonly used to secure REST, gRPC, and GraphQL APIs by verifying a user's identity?

    1. Request throttling
    2. XML sitemap enforcement
    3. URL query filtering
    4. Token-based authentication

    Explanation: Token-based authentication securely transmits a user's credentials and is widely used across REST, gRPC, and GraphQL APIs. URL query filtering and XML sitemaps serve other purposes, while throttling limits requests but does not verify identities. Thus, tokens are the standard for user verification.

  10. Versioning Web APIs

    What is a common method for indicating the version of a REST API, for instance, to provide both v1 and v2 endpoints?

    1. Including the version in the URL path, such as /api/v2/resource
    2. Setting an expiration date in the header
    3. Using HTTP methods to specify the version
    4. Changing the HTTP protocol

    Explanation: Including the version directly in the URL path is a clear and common practice for REST API versioning. HTTP methods do not indicate versions, headers may contain version info but are less visible, and changing the HTTP protocol is unrelated. Placing the version in the route helps clients and developers easily track API changes.