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.
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?