To get information about songs in an album,

we're going to use the look up end point again.

The only difference this time around is instead of the album entity,

we're going to specify song.

So back in Postman, we'll copy the base URL, so from here we're

gonna get everything up to lookup, again, and in a new tab we'll paste this in.

And like with the album, the way we're gonna search for

a song is to provide an ID to lookup.

Instead of an artist ID, we're going to the ID of an album,

which back in our response here, if I hit Send to get that again.

And then load this into JSON.

So if we look here, we have a collection which is an album, and

it has a collection ID.

So let's copy this and grab the collection ID for the first album.

And then back in our final request in our lookup, we're going to specify here,

under params, an ID.

And we'll paste in that value and then for the entity we'll say song.

Done and done, okay let's hit Send.

Again we'll have to switch this to JSON.

Just like before we have a results array with nest to dictionaries.

And like the album queries started off with a dictionary that contained

information about the artist.

The first item in the results array for

the song query is a dictionary containing information about the album.

Now, we're not going to use any of these data though because on the final detail

page, we're going to use the album class as our model and

we already have this information.

So what are we gonna get?

Let's scroll down to the next section.

Here we have a dictionary that represents a song.

So the wrapper type is track and the kind is song.

And there is a lot of information here.

We're going to keep it simple and we'll use the track ID,

the track name, we'll also grab the tracks censored name.

We'll get the tracked time down here which is in milliseconds.

And then finally, whether the track is explicit or not.

If you want any of the other info, go for it.

So now let's jump back to Xcode and in the Song struct we created earlier,

let's add these relevant stored properties.

So id, type Int, name, String.

censoredName also a string, let trackTime, this is an Int.

And finally whether the the track is explicit or not, and that's a Bool.

Now one thing I want to point out are types.

So Album, Song, and Artist all have stored properties that have the same name.

So we have an id here, we have a name here.

And in out JSON response these have different names.

So collection id, artist id.

The reason we're not using those names in here is because

the type provides some name spacing.

So when I refer to this property it'll be song.name or artist.name or album.name.

So there is already that meaning there and

I don't have to get some redundant information in the stored property name.

We don't want album.ablumname for example.

Now since this is a struck, we get the member wise initializer, so

we don't need to type on out manually.

And with that, we have all our models.

So now is the interesting bit,

let's use these models to create some faked data to use as a stub in our app.

What's a stub?

Well, in this context,

it is some code that we can use as a stand in for actual functionality.

Eventually, we want data from the web and to use that data in our UI.

But just for the sake of setting up our UI,

getting real data involves a fair bit of work.

We need to model our endpoints.

We need to write networking code.

We need to parse the results and so on.

By using fake data we can immediately start building the UI and

getting something barebones up on the screen.

We won't run into any errors with the data because it is a placeholder that we

define.

And then once we're done with the UI we can circle back and

figure out how to get real data.

Which is a separate problem on its own with its own set of complexities.

So let's add a final file to this model's group.

We'll call this Stub.

And in here, we're going to model a fake response in exactly the same way we

expect to get back from the web.

So we'll start with the struct and we're doing this just so

that we have some name spacing again.

And the stub is going to be a simple struct with a series of computed

properties.

For example, we'll start with artist, static var artist of type artist.

Now, in this property, let's return an instance of artist populated with data

that we can grab from the JSON response in Postman for it looking up an Artist term.

So we'll say a return Artist, and then you can go over

to Postman, and in this first response here where we look up an Artist,

let's grab the JSON, and here we'll grab some data from the first result.

So, we want an artistId, so we'll copy that, and

the rest of the stuff I can just type out myself.

So I'll paste this in, the name is Taylor Swift.

PrimaryGenre is pop, and the albums, well, an empty array for now.

When we search for

an artist term, even though our model contains a stored property for

the albums, the actual JSON response doesn't have any of that information.

We already know that.

To get this, we need to make that second lookup call.

So here, we're just going to return an empty array for the albums.

And this is what I mean in that our stub will model the exact same response

as our web request.

When we get an artist for the first time, albums will be empty so

we need to do some additional work to get the album value.

Okay, so that's it for artist and next is an array of albums.

Again, this is a bunch of copy pasting, so you can either do it on your own,

go back and forth between Postman and get the relevent data, or

just ground the code from the snippet in the teachers notes.

That snippet includes all of the stub data, so

you can just simply paste it all in.

Let's take a break here.

Over the next set of videos we'll get our entire UI up and

running to display all of this fake data.