EasyExperience level: 0-2 years · 3-5 years1 min read

Request JSON vs Response JSON — Interview Questions

Reviewed by Gurusankar M.

Asked inAmazonMicrosoftDeloitteInfosys
#json#request#response#dto#api design
Report issue

Short Answer

Request JSON is the payload the client sends (the input the user controls); response JSON is what the server returns (the result). Their shapes usually differ: a request shouldn't include server-generated fields (id, createdAt, computed totals), and a response often adds them plus metadata. Modeling them as separate DTOs keeps inputs safe and outputs rich.

On this page

Concept Made Simple

Coffee Chat Question

“What is the difference between request JSON and response JSON?”

Remember It Faster

Mind Map Answer

Request JSON
client → server (input)
Response JSON
server → client (result)
Request omits
id, createdAt, computed fields
Response adds
ids, timestamps, links, metadata

Learn by Doing

Hands-on Keyboard

json
// Request (create a user) — no id/createdAt
{ "name": "Guru", "email": "guru@example.com" }

// Response — server-generated fields added
{ "id": 101, "name": "Guru", "email": "guru@example.com",
  "createdAt": "2026-08-01T09:00:00Z" }

Think Beyond the Expected

What If?

Why shouldn't the client be allowed to send fields like id, role, or isAdmin in the request?

Because inputs are attacker-controllable. If the server blindly binds request JSON onto its entity ('mass assignment'), a user could set isAdmin=true or overwrite someone else's id. Use a request DTO with an explicit allow-list of fields, and let the server own generated/privileged fields.

Real World

Separate request/response DTOs are standard in Spring, NestJS, etc. — the request DTO validates and allow-lists user input; the response DTO shapes output (hiding internals like password hashes). Conflating them causes mass-assignment vulnerabilities.

Interviewer's Expectation

Keywords they're listening for:

  • request = input, response = result
  • different shapes
  • requests omit server-generated fields
  • mass-assignment risk
  • separate DTOs

Common Mistakes

  • Binding request JSON directly onto entities
  • Letting clients set privileged fields
  • Leaking internal fields in responses

Best Practices

  • Use separate, allow-listed request DTOs
  • Shape responses to hide internals
  • Validate every request payload

Follow-up Questions

  1. What is a mass-assignment vulnerability?
  2. Why hide fields like password hashes in responses?
  3. How do request/response schemas appear in OpenAPI?

Continue Learning with AI

Take this question deeper with your favourite AI assistant. Pick a depth, copy the prompt, or open it directly — AI is your learning companion, not a shortcut.

Plain-language foundations

I'm preparing for a software engineering interview and want to understand this from scratch, as a beginner.

Topic: REST APIs (JSON)
Interview question: "What is the difference between request JSON and response JSON?"

Please:
1. Explain the core idea in simple, plain language, using an everyday analogy.
2. Define any technical terms you use.
3. Walk through one small, concrete example.
4. Finish with a single sentence I can easily remember.

Keep the tone friendly and assume I'm new to this topic.
Open inChatGPTGeminiClaude

Was this answer helpful?

Affiliate links

Tools for Your Developer Workspace

Equipment for a comfortable, productive setup.

As an Amazon Associate I earn from qualifying purchases.