— how our application speaks back to the world

Once a controller performs an action,
something needs to go back to
the outside world.

That “something” is a 'response'.

And just like routing, queries, and API calls,
the shape is simple:

A 'response' is a small, intentional message
from our application to whoever asked.

It can be:

• a string
• an array
• JSON
• HTML
• a status code
• a redirect
• or even nothing

The important part is not the format
— it’s the meaning.

A controller can return a simple string:

return 'About page';

Our router echoes it:

echo $controller->about();

This is the smallest possible response.
It’s not wrong.
It’s not outdated.
It’s simply the beginning.

As soon as we want to return structured data,
we return an array:

return [
    'id' => $user->id,
    'name' => $user->name,
];

Our router or front controller can convert it to JSON:

header('Content-Type: application/json');
echo json_encode($data);

This is the shape:

• controller returns meaning
• front controller decides format

This separation keeps our domain clean.

To keep things calm, we can give 'JSON responses' a home:

function json(array $data, int $status = 200): void {
    http_response_code($status);
    header('Content-Type: application/json');
    echo json_encode($data);
}

Now our controller reads like a story:

return json(['status' => 'ok']);

This is the moment when responses become expressive.

A response can also express failure:

return json(['error' => 'User not found'], 404);

No stack traces.
No HTML error pages.
No noise.

Just a clear message.

When we ask AI to “return a response,” it may:

• mix HTML and PHP
• echo inside controllers
• return JSON inconsistently
• skip status codes
• generate framework‑specific code
• over‑engineer the response layer

Our literacy lets us steer the conversation:

“Keep the response simple.”

“Return meaning, not markup.”

“Use JSON for structured data.”

“Set the status code explicitly.”

“Keep the controller thin.”

We’re not memorizing response systems
— we’re shaping intention.

Let’s say we want to show a user.

Our controller:

public function show(string $id): array {
    $user = $this->users->find($id);
 
    if (!$user) {
        return ['error' => 'User not found', 'status' => 404];
    }
 
    return [
        'id' => $user->id,
        'name' => $user->name,
    ];
}

Our front controller:

$data = $controller->show($id);
 
$status = $data['status'] ?? 200;
unset($data['status']);
 
json($data, $status);

The controller returns meaning.
The front controller returns format.

This is the separation that keeps our application calm.

====

The moment when returning strings stops being enough

Here’s what that moment looks like.

We may start with:

“Return the user as JSON.”

AI gives us:

echo json_encode($user);

Then we ask:

“Also set the status code.”

AI adds more code.

Then we ask:

“Also set the content type.”

More code.

Then we ask:

“Also handle errors.”

Even more code.

We feel the friction.
we feel the repetition.
we feel the concept.

This is the moment to say:

“Give me a simple response helper 
that returns JSON with a status code.”

AI will produce a clean helper.

This is the literacy we’re learning:

When responses repeat, we ask for a helper.
When responses grow, we give them a home.

A response is not a string — it’s meaning.
Format is secondary.
Clarity is primary.

Once we see this shape,
we can collaborate with AI on any response system
— from a tiny script to a full framework —
without losing our calm.

_{Tony de Araujo —New York}

• Top↑
• Back to Topic ↔
• Home←