IT 260 Web-Oriented Services Comprehensive Final Exam
Practice Questions and Detailed Solutions Latest Update
2026/2027 | REST APIs, Web Services, JSON, Verified Answers
- 190 Questions
Comprehensive final exam covering architectural styles, HTTP semantics, resource design, JSON/XML
processing, security, versioning, caching, and API testing. Emphasizes contemporary standards such as OpenAPI
3.x, OAuth 2.1, and RFC 7807. It contains 190 multiple-choice questions, each with four distractors and a fully
worked rationale that explains why the keyed answer is correct. Questions are organized into clearly labelled
sections that mirror the major content areas of the course. Targeted learning outcomes include: Analyze and
design RESTful APIs using resource-oriented architectures and HATEOAS constraints.; Evaluate trade-offs
between REST, GraphQL, gRPC, and SOAP in real-world integration scenarios.; Apply advanced HTTP features
including caching, conditional requests, and content negotiation.; Implement security mechanisms including
OAuth 2.1, JWT, and API keys with appropriate threat modeling.. Every item has been reviewed for clinical
accuracy, current guidelines, and clarity so that students can study with confidence and self-correct as they work
through the bank. Use it as a high-yield review immediately before the exam, or as a structured practice tool
during the unit - the rationales double as concise teaching notes. The recommended writing time is 3 hours, with a
passing score of 70%. Aligned with Aligns with ABET computing accreditation criteria and ACM/IEEE Computer
Science curricula guidelines. standards and reflects the question style commonly seen on accredited program
examinations. Students consistently achieving above the cut score on this bank have historically gone on to earn
Section 1: General (Questions 1-190)
1 Given an API that consistently returns HTTP 200 with a JSON body
containing a 'status' field to indicate errors, which architectural
principle does this most directly violate?
A) Uniform interface
B) Statelessness
C) Self-descriptive messages
D) HATEOAS
Answer: C
Rationale: Self-descriptive messages require that each response
includes enough metadata (e.g., status codes, media types) for the
client to interpret it without out-of-band information. Using a 200
status with an embedded error status hides the error semantics from
intermediaries and violates this constraint. Uniform interface (A) is
broader, statelessness (B) is about server-side state, and HATEOAS
(D) concerns hypermedia-driven navigation.
,2 In designing a RESTful API for a multi-tenant SaaS, which
approach best ensures that a client cannot access another tenant's
resources via a predictable ID?
A) Use UUIDs instead of sequential integers for resource IDs.
B) Include tenant ID in the URL path and validate it against the
authenticated principal.
C) Rely on the API gateway to strip tenant identifiers from requests.
D) Encrypt resource IDs with a server-side secret.
Answer: B
Rationale: Tenant isolation requires authorization checks on every
request. Including the tenant ID in the URL and validating it against
the authenticated principal ensures that a client can only access
resources within their own tenant, even if they guess other IDs.
UUIDs (A) make guessing harder but do not prevent access if the ID
is known; encryption (D) is similarly obscurity. Relying on the
gateway (C) without app-level checks is insecure.
3 An API client receives a 304 Not Modified response for a GET
request that included an If-None-Match header. What can the client
safely conclude?
A) The resource has been deleted permanently.
B) The cached representation is still valid and can be used.
C) The server does not support ETags.
D) The client must re-authenticate before receiving the full response.
Answer: B
Rationale: A 304 response indicates that the conditional GET
evaluated the ETag and found that the client's cached version matches
the current representation, so the cache is fresh. It does not imply
deletion (A), lack of ETag support (C), or authentication issues (D).
The client can continue to use its cached copy.
, 4 When designing a public API that must support both
human-readable responses and machine-optimized responses, which
HTTP mechanism is most appropriate?
A) Different URL paths for each format (e.g., /api/v1/report and
/api/v1/report.json).
B) Content negotiation using the Accept header and multiple media
types.
C) Query parameter '?format=json' to switch formats.
D) Returning JSON by default and HTML only on error.
Answer: B
Rationale: Content negotiation allows the same URI to serve different
representations based on the client's Accept header, preserving the
uniform interface and cacheability. URL suffixes (A) and query
parameters (C) fragment the resource space and complicate caching
and documentation. Returning only JSON (D) does not serve
human-readable needs.
5 A RESTful API uses the following JSON: { "user": { "name":
"Alice", "address": { "city": "Springfield" } } }. Which refactoring
best improves compliance with the 'use of namespaced, extensible
schemas' best practice?
A) Flatten the nested objects into a single level.
B) Add a 'type' field to every object.
C) Introduce a JSON Schema with $schema and definitions for each
object.
D) Rename keys to camelCase such as 'userName'.
Answer: C
Rationale: JSON Schema provides a formal, extensible way to define
the structure, types, and constraints of JSON data, supporting
namespaces and versioning. Flattening (A) reduces readability and
extensibility; adding a 'type' field (B) is ad hoc; renaming keys (D)
does not add machine-readable schema.
, 6 For a long-running operation that creates a resource asynchronously,
which HTTP pattern is most aligned with REST principles?
A) Return 202 Accepted with a Location header pointing to a status
resource.
B) Return 200 OK with the final resource representation after a
blocking wait.
C) Return 201 Created immediately with the resource representation
and a background job ID.
D) Return 303 See Other to redirect to a polling URL.
Answer: A
Rationale: The asynchronous request-response pattern uses 202
Accepted to acknowledge receipt, and a Location header to indicate a
status resource that the client can poll to track progress. This keeps the
API responsive and resource-oriented. Blocking (B) is not scalable;
201 (C) implies immediate creation; 303 (D) is for redirecting after a
POST result, not for async status.
7 Which versioning strategy best supports both backward
compatibility and the ability to evolve an API without breaking
existing clients?
A) Breaking changes are allowed in minor versions.
B) Use URI versioning (e.g., /v1/, /v2/) and maintain old versions
indefinitely.
C) Use custom media types (e.g., application/vnd.api.v2+json) and
deprecate old versions with a sunset header.
D) Avoid versioning and make all changes backward compatible.
Answer: C
Rationale: Custom media types allow content negotiation and keep the
URI stable, while a deprecation policy with a Sunset header informs
clients of end-of-life. Maintaining old versions indefinitely (B) is
costly, and avoiding versioning (D) is impractical for real evolution.
Allowing breaking changes in minor versions (A) violates semantic
Practice Questions and Detailed Solutions Latest Update
2026/2027 | REST APIs, Web Services, JSON, Verified Answers
- 190 Questions
Comprehensive final exam covering architectural styles, HTTP semantics, resource design, JSON/XML
processing, security, versioning, caching, and API testing. Emphasizes contemporary standards such as OpenAPI
3.x, OAuth 2.1, and RFC 7807. It contains 190 multiple-choice questions, each with four distractors and a fully
worked rationale that explains why the keyed answer is correct. Questions are organized into clearly labelled
sections that mirror the major content areas of the course. Targeted learning outcomes include: Analyze and
design RESTful APIs using resource-oriented architectures and HATEOAS constraints.; Evaluate trade-offs
between REST, GraphQL, gRPC, and SOAP in real-world integration scenarios.; Apply advanced HTTP features
including caching, conditional requests, and content negotiation.; Implement security mechanisms including
OAuth 2.1, JWT, and API keys with appropriate threat modeling.. Every item has been reviewed for clinical
accuracy, current guidelines, and clarity so that students can study with confidence and self-correct as they work
through the bank. Use it as a high-yield review immediately before the exam, or as a structured practice tool
during the unit - the rationales double as concise teaching notes. The recommended writing time is 3 hours, with a
passing score of 70%. Aligned with Aligns with ABET computing accreditation criteria and ACM/IEEE Computer
Science curricula guidelines. standards and reflects the question style commonly seen on accredited program
examinations. Students consistently achieving above the cut score on this bank have historically gone on to earn
Section 1: General (Questions 1-190)
1 Given an API that consistently returns HTTP 200 with a JSON body
containing a 'status' field to indicate errors, which architectural
principle does this most directly violate?
A) Uniform interface
B) Statelessness
C) Self-descriptive messages
D) HATEOAS
Answer: C
Rationale: Self-descriptive messages require that each response
includes enough metadata (e.g., status codes, media types) for the
client to interpret it without out-of-band information. Using a 200
status with an embedded error status hides the error semantics from
intermediaries and violates this constraint. Uniform interface (A) is
broader, statelessness (B) is about server-side state, and HATEOAS
(D) concerns hypermedia-driven navigation.
,2 In designing a RESTful API for a multi-tenant SaaS, which
approach best ensures that a client cannot access another tenant's
resources via a predictable ID?
A) Use UUIDs instead of sequential integers for resource IDs.
B) Include tenant ID in the URL path and validate it against the
authenticated principal.
C) Rely on the API gateway to strip tenant identifiers from requests.
D) Encrypt resource IDs with a server-side secret.
Answer: B
Rationale: Tenant isolation requires authorization checks on every
request. Including the tenant ID in the URL and validating it against
the authenticated principal ensures that a client can only access
resources within their own tenant, even if they guess other IDs.
UUIDs (A) make guessing harder but do not prevent access if the ID
is known; encryption (D) is similarly obscurity. Relying on the
gateway (C) without app-level checks is insecure.
3 An API client receives a 304 Not Modified response for a GET
request that included an If-None-Match header. What can the client
safely conclude?
A) The resource has been deleted permanently.
B) The cached representation is still valid and can be used.
C) The server does not support ETags.
D) The client must re-authenticate before receiving the full response.
Answer: B
Rationale: A 304 response indicates that the conditional GET
evaluated the ETag and found that the client's cached version matches
the current representation, so the cache is fresh. It does not imply
deletion (A), lack of ETag support (C), or authentication issues (D).
The client can continue to use its cached copy.
, 4 When designing a public API that must support both
human-readable responses and machine-optimized responses, which
HTTP mechanism is most appropriate?
A) Different URL paths for each format (e.g., /api/v1/report and
/api/v1/report.json).
B) Content negotiation using the Accept header and multiple media
types.
C) Query parameter '?format=json' to switch formats.
D) Returning JSON by default and HTML only on error.
Answer: B
Rationale: Content negotiation allows the same URI to serve different
representations based on the client's Accept header, preserving the
uniform interface and cacheability. URL suffixes (A) and query
parameters (C) fragment the resource space and complicate caching
and documentation. Returning only JSON (D) does not serve
human-readable needs.
5 A RESTful API uses the following JSON: { "user": { "name":
"Alice", "address": { "city": "Springfield" } } }. Which refactoring
best improves compliance with the 'use of namespaced, extensible
schemas' best practice?
A) Flatten the nested objects into a single level.
B) Add a 'type' field to every object.
C) Introduce a JSON Schema with $schema and definitions for each
object.
D) Rename keys to camelCase such as 'userName'.
Answer: C
Rationale: JSON Schema provides a formal, extensible way to define
the structure, types, and constraints of JSON data, supporting
namespaces and versioning. Flattening (A) reduces readability and
extensibility; adding a 'type' field (B) is ad hoc; renaming keys (D)
does not add machine-readable schema.
, 6 For a long-running operation that creates a resource asynchronously,
which HTTP pattern is most aligned with REST principles?
A) Return 202 Accepted with a Location header pointing to a status
resource.
B) Return 200 OK with the final resource representation after a
blocking wait.
C) Return 201 Created immediately with the resource representation
and a background job ID.
D) Return 303 See Other to redirect to a polling URL.
Answer: A
Rationale: The asynchronous request-response pattern uses 202
Accepted to acknowledge receipt, and a Location header to indicate a
status resource that the client can poll to track progress. This keeps the
API responsive and resource-oriented. Blocking (B) is not scalable;
201 (C) implies immediate creation; 303 (D) is for redirecting after a
POST result, not for async status.
7 Which versioning strategy best supports both backward
compatibility and the ability to evolve an API without breaking
existing clients?
A) Breaking changes are allowed in minor versions.
B) Use URI versioning (e.g., /v1/, /v2/) and maintain old versions
indefinitely.
C) Use custom media types (e.g., application/vnd.api.v2+json) and
deprecate old versions with a sunset header.
D) Avoid versioning and make all changes backward compatible.
Answer: C
Rationale: Custom media types allow content negotiation and keep the
URI stable, while a deprecation policy with a Sunset header informs
clients of end-of-life. Maintaining old versions indefinitely (B) is
costly, and avoiding versioning (D) is impractical for real evolution.
Allowing breaking changes in minor versions (A) violates semantic
