By conforming to the end point protocol, the iTunes enum let's us

easily create URLs for making requests to the search API.

But we haven't modeled it exactly how we want.

When we played around with the API in postman, we used the entity and attribute

keys to restrict the search even further and keep our results somewhat sane.

If we go back to the documentation again, and take a look at the entity and

attributes keys in the parameters list, you'll see that it's not straightforward.

Like the media key entity has subsets of values that

depend on the media types selected, and same goes for the attribute.

There are a couple ways we can model this, but ultimately the end goal

is to make the final use site as easy and as clear as possible.

To our endpoint group over here, let's add a new Swift file, and

we'll call this iTunes entity.

The first approach that comes to mind is to create an enum called iTunes entity

to model the top level entity types.

Now, these are the same values as encapsulated in the iTunes media type, so

let's just go to the media enum right here, and we'll copy paste this over.

Instead of calling it ItunesMedia,

we'll call this ItunesEntity but this isn't sufficient, right?

For the music case right here,

there are six possible entity values we can include in the parameter as a value.

We can modify each of these enum members,

to carry those specific arguments as associated values.

For example, let's create another type here, we'll create a second enum and

we'll call this music entity and model the actual value as members of this type.

So we'll say case musicArtist, musicTrack and

these are the same values that are listed in the description section for

the entity key or under music at least.

And case album,

case musicVideo, mix and song.

Now the purpose of this type is to allow us to specify the value for

the entity parameter easily without resorting to strings.

So one way we can do that is by conforming to custom string convertible and

returning the string we need for the value.

So if I make this enum have a rawValue of a String,

we can then in an extension of MusicEntity

conform to CustomStringConvertable and we'll just return for

the description key the Strings or the enums rawValue.

But this isn't entirely useful.

Because in the iTunes enum, we're using the ItunesEntity, or

we plan to use the ItunesEntity, as our top-level type.

So what do I mean by that?

Back in the ItunesEntity, over here,

we can add an associated value to each member that provides information

about each subset modeled by these furthered types that we've described.

So in the music case for example,

we can say case music carries an associated value of type MusicEntity.

Without implementing the rest, so movie, podcast,

none of these, let's see how this would work out.

So here we have a top level enum ItunesEntity, and

it has cases to represent each media type.

Each media type then carries as an associated value,

the values for the entity under that category.

So music contains all the music entity values.

Which are these, one, two, thee, four, five, six.

So how are we gonna use this?

Let's go back to the endpoint file and

in the iTunes enum, let's add an associated value for the entity.

So here we'll say entity of type ItunesEntity.

And again this is going to be optional.

We'll get an error now and that's because the switch statement inside the query

items computer property needs to be fixed.

The enum case we're matching against is now incorrect because over here

we're not accounting for the entity value, we just add it as an associated value.

So we'll say let entity.

Now once we add that, we can try and

get the entity parameter into our query items array.

So over here, first, we need to unwrap it.

Entity being an optional.

So we'll say if let entity = entity.

Now, unfortunately inside here, it's not so easy to get at that value.

The entity type here is represented by an enum, it's that top level iTunes enum.

We need to switch on to each case and

then each of those cases members has an associated value.

And that associated value is also represented by an enum.

Anyway, let's give it try.

And for the sake of exploring again, we'll just focus on the music case.

So inside of here, I can say switch on the entity.

And we'll say case .music.

And it carries an associate value to represent the music entity.

So say, let entity, or let musicEntity to make it more clear.

And now inside here, I can say let musicEntity =

URLQueryItem Name is entity and

the value is music entity.description.

Because remember, we added that conformance.

Finally we can append this to the result.

And now we have the music entity value inside of our array.

Let's just add a default case for the rest since we're not going to implement it, and

we'll break out of the switch statement.

This is a lot of work already, and

remember, we're just covering one entity here.

If we really want to model all the entity values, this is going to be a very large

switch statement because we have to match on each case, get that associative

value as an entity and then duplicate these lines of code for every single one.

And then, after we do all that, we then have to cover the attributes case.

So let's ignore all of that right just for

now we'll pretend that this is the way we want to go.

Let's see how this works out.

So if we go to the ViewController.swift we can now

test how this writes at the call site.

So Itunes.search now is an error because we have an entity associated value.

And for this we'll say .music because first we need that top level type

ITunesEntity and

then inside of the associated value you could say .musicArtist.

If we run now, in the console we have the value that we want So

this seems okay at first but theres one obvious and one subtle thing going on.

The obvious bit that pops out to me at the call site

is that there is a lot of repetition.

We've specified that the media type is music and then the entity type is

also music and then the actual values deep in there and that is music artists.

The non-obvious thing though, is that because the arguments for media and

entity are separate arguments with different types, there's nothing

preventing me from specifying the media as music and the entity as podcast.

Then something we said, we explicitly want to avoid.

We don't want to have to think about these things, right.

I don't want you to remember that this

is going to end up in an error on the service site.

So this is a no-go for me.

This approach is not gonna work.

In the next video, let's take a look at this problem in a different manner