At the bottom, you can see that response has programmer and project information
right inside of it. That's because the Battle class has two properties that
hold these objects. The serializer sees these objects, and serializes them
recursively.

In a couple of chapters, we're going to talk about embedding resources where
we do this on purpose. But for now, I want to avoid it: if I'm getting a
Battle, I only want to retrieve that Battle. So like before, we need
to take control of how this is serialized.

I'll copy the Serializeruse statement from Programmer into Battle.
Next, let's also copy the ExclusionPolicy annotation into Battle, which
tells the serializer to only serialize properties that we explicitly expose
with the @Serializer\Expose annotation. Which properties you want to expose
is totally up to you. I'll do it with the $id, of course $didProgrammerWin,
$foughtAt and we'll also expose the $notes property:

So how can we add this? The problem is that there really is noprogrammerUri
property on Battle. So one of the cool features from JMS serializer is
the ability to have virtual properties.

Create a new function called getProgrammerUri - the name of the method
is important - and for right now, I'm just going to hardcode in the URL instead
of generating it from the name like we have been doing. I'll fix that later: