Implement a REST GET Endpoint and Evolve Its Contract Safely

Read the full interview experience this question came from →

Quick Overview

Discuss a concrete read-endpoint plan, safe and idempotent semantics, error handling, and compatibility when an API contract changes.

Implement a REST GET Endpoint and Evolve Its Contract Safely

Company: Generalmotors

Role: Software Engineer

Category: Software Engineering Fundamentals

Difficulty: medium

Interview Round: Technical Screen

Explain how you would implement a RESTful GET endpoint, reason about idempotency, and evolve its API contract without unexpectedly breaking clients. ### Part 1 — Implement the Read Endpoint Choose an illustrative language and a simple resource, then describe routing, parameter validation, authorization, data access, response shape, and error handling. #### What This Part Should Cover A coherent read-only endpoint with explicit assumptions, status behavior, and separation of internal failures from a missing resource. ### Part 2 — Idempotency and Contract Changes Explain what idempotency means for GET and for other operations. Then discuss how you would change response fields or behavior while maintaining client compatibility. #### What This Part Should Cover Idempotency as intended server effect rather than identical responses, safe read semantics, compatibility, versioning, and migration evidence. ### Constraints The source endpoint's resource, schema, and framework are unspecified. Your chosen example is hypothetical. Do not claim that an arbitrary GET request must return the same bytes forever or that adding any field is always safe for every client. ### Clarifying Questions - What resource is read, and who is authorized to access it? - Which clients depend on the existing response and error contract? - Does the proposed change alter field meaning, required inputs, or caching behavior? ```hint Separate response variation from side effects A resource can change between two safe GET requests even though repeating the request does not itself change the intended server state. ``` ### What a Strong Answer Covers - A concrete language-level endpoint plan with validation and authorization. - Correct safe/idempotent semantics and an appropriate mutation-retry discussion. - A staged, evidence-based approach to API compatibility. ### Follow-up Questions - How would an idempotency key help a retried creation request? - How would you migrate clients when a field's meaning changes?

Overview: Discuss a concrete read-endpoint plan, safe and idempotent semantics, error handling, and compatibility when an API contract changes.

Read the full Generalmotors Software Engineer interview experience this question came from

|Home/Software Engineering Fundamentals/Generalmotors
Generalmotors logo
Generalmotors
Aug 30, 2026
mediumSoftware EngineerTechnical ScreenSoftware Engineering Fundamentals
0
0

Explain how you would implement a RESTful GET endpoint, reason about idempotency, and evolve its API contract without unexpectedly breaking clients.

Part 1 — Implement the Read Endpoint

Choose an illustrative language and a simple resource, then describe routing, parameter validation, authorization, data access, response shape, and error handling.

What This Part Should Cover Guidance

A coherent read-only endpoint with explicit assumptions, status behavior, and separation of internal failures from a missing resource.

Part 2 — Idempotency and Contract Changes

Explain what idempotency means for GET and for other operations. Then discuss how you would change response fields or behavior while maintaining client compatibility.

What This Part Should Cover Guidance

Idempotency as intended server effect rather than identical responses, safe read semantics, compatibility, versioning, and migration evidence.

Constraints

The source endpoint's resource, schema, and framework are unspecified. Your chosen example is hypothetical. Do not claim that an arbitrary GET request must return the same bytes forever or that adding any field is always safe for every client.

Clarifying Questions Guidance

  • What resource is read, and who is authorized to access it?
  • Which clients depend on the existing response and error contract?
  • Does the proposed change alter field meaning, required inputs, or caching behavior?

What a Strong Answer Covers Guidance

  • A concrete language-level endpoint plan with validation and authorization.
  • Correct safe/idempotent semantics and an appropriate mutation-retry discussion.
  • A staged, evidence-based approach to API compatibility.

Follow-up Questions Guidance

  • How would an idempotency key help a retried creation request?
  • How would you migrate clients when a field's meaning changes?
Loading comments...